I see we currently use the %{_libdir} prefix in the spec file for the install location, and install it similarly based on the autoconf/automake $(libdir) path in the package makefile...

I think in the autoconf side to fix that we probably change server/Makefile.am:

systemddir=$(libdir)/systemd/system

to

systemddir=$(prefix}/lib/systemd/system

and then fix the spec files...

Yep.

Also, the unit file is a bit too complex this one work fine :

# cat /etc/systemd/system/sipwitch.service 
[Unit]
Description=GNU SIP Witch, a SIP telephony service daemon.
After=network.target

[Service]
Type=simple
PIDFile=/var/run/sipwitch/pidfile
EnvironmentFile=-/etc/conf.d/sipwitch
EnvironmentFile=-/etc/sysconfig/sipwitch
EnvironmentFile=-/etc/default/sipwitch
ExecStart=/usr/sbin/sipw -f $OPTIONS
Restart=always

[Install]
WantedBy=multi-user.target


There is no need to sleep with type=simple, since systemd will wait on the process to stopped. It also send a simple sigterm so there is no need to write "stop" to the control socket. 

I have removed the removal of the socket, but maybe if sipwitch crash, it should be kept. I was just in a cleaning spree :)

Well, it was my very first systemd unit file :)

Do we really want to run sipw in foreground mode?  Well, I guess since it is already deamonfied through systemd, that part does not matter, and certainly it is easier to track the final pid.  And yes, this makes the rest of it simpler.

(In reply to Michael Scherer from comment #2)
> Yep.
> 
> Also, the unit file is a bit too complex this one work fine :
> 

All of this I took as an upstream fix for 1.8.7.  Of course, it also was easy to rebuild/update in rawhide.  I am looking for an opinion on F20, however...

In F19/F20, I kept sipwitch at 1.6.1.  This is because all work past that really was for supporting the newer exosip2 4.x api (which is supported alongside the older exosip2 releases), and F20 did not have this as yet.

I could migrate F20 to 1.8.7, or I could do a patch for 1.6.1.  Offhand I see no real downside to updating F20 to 1.8.7, and really it does not effect/does not have any impact on any other Fedora packages.  But I am hoping to get some additional feedback before arbitrarily doing so.

> # cat /etc/systemd/system/sipwitch.service 
> [Unit]
> Description=GNU SIP Witch, a SIP telephony service daemon.
> After=network.target
> 
> [Service]
> Type=simple
> PIDFile=/var/run/sipwitch/pidfile
> EnvironmentFile=-/etc/conf.d/sipwitch
> EnvironmentFile=-/etc/sysconfig/sipwitch
> EnvironmentFile=-/etc/default/sipwitch
> ExecStart=/usr/sbin/sipw -f $OPTIONS
> Restart=always
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> There is no need to sleep with type=simple, since systemd will wait on the
> process to stopped. It also send a simple sigterm so there is no need to
> write "stop" to the control socket. 
> 
> I have removed the removal of the socket, but maybe if sipwitch crash, it
> should be kept. I was just in a cleaning spree :)

While I would be very conservative on stable upgrade, this is on the other hand a software you know quite well, and that seems quite stable. And having a new version would provides more feedback to you as upstream. So I would go for a upgrade.

sipwitch-1.8.7-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sipwitch-1.8.7-1.fc20

Package sipwitch-1.8.7-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sipwitch-1.8.7-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-1566/sipwitch-1.8.7-1.fc20
then log in and leave karma (feedback).

*** Bug 1058966 has been marked as a duplicate of this bug. ***

sipwitch-1.8.7-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Now that Debian has chosen systemd too, I have decided to add sd_notify support in the next pending release (1.8.9||1.9.0), as there is an internal "up" flag in sipw itself that gets set when it is "really" up and ready.  That seems to be what sd_notify READY=1 is for...  So I will have a new unit file with Type=notify starting with that release (and tied to a new sipw "-S" option...) rather than overloading use of -f mode, which really was originally meant for debugging.

I would also recommend looking at the new monitoring protocol that is being implemented in the next systemd version, to restart sipw in case of freeze, but that should wait until systemd is out this week ( and wait until a backport or something, that's just a FYI ). The protocol is quite easy, just sending some message using sd_notify every X/2 seconds to notify the watchdog, that can be integrated quite easyly in the main loop ( most of the time, didn't look at sipw code but I do not expect much issues ).

I am not sure a closed bug report is the best place to discuss this, but yes, we actually do have a heartbeat thread in sipw itself to do housecleaning and internal reaping, and it would seem rather natural to do so from that.  I am going to experiment with systemd changes and integration in rawhide for F21 rather than effect F20, of course.  Perhaps it should be submitted and discussed formally as a F21 "changes" proposal on the Fedora wiki, but it seems rather small for that...

If we do add heartbeat notifications from sd_notify for newer systemd, are they ignored when ran on systems with older systemd releases?  Or will we have to explicitly test systemd versions at build time?  If there are changes in the unit file to enable monitoring support, do older systemd releases ignore that?

yeah, agreed, maybe we shouldn't discuss here :)

And yes, message are ignored, there is future proofing.