Shibboleth SP on RHEL7- issues between shibd <-> systemd?

[Ferenc Wagner]

Jarno Huuskonen <jarno.huuskonen at uef.fi> writes:

> On Mon, Jun 08, Ferenc Wagner wrote:
>
>> "Cantor, Scott" <cantor.2 at osu.edu> writes:
>> 
>>> On 6/1/15, 10:04 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>>>
>>> Well, if stopping doesn't work without that change, that's still new
>>> information to me, I wasn't aware. That, I guess, suggests it's not
>>> actually running the init script to stop it, it must be tracking the
>>> PID inside that abomination and only stopping the forked process it
>>> records.
>>>
>>> Same result for me, I'll add something to the systemd issue in Jira.
>> 
>> Could you please point me at this issue?  Systemd integration is
>> something we'll have to tackle in the Debian packaging, too.
>
> I've been using this shibd.service file with rhel7/centos7 and it
> seems to work just fine. AFAIK with -F (shibd doesn't fork) the wait
> timeout is ignored. So too short -w timeout shouldn't be a problem.

Right, but this way (Type=simple) systemd gets no feedback about when
shibd actually starts servicing requests.  So even though you order it
to start before httpd.service, the HTTP daemon may well be running
before shibd initializes its listener socket.

> I think that systemd/shibd integration could be improved:
> with systemd use SD_INFO / SD_ERR / SD_CRIT when writing errors(from
> shibd.cpp) to stderr
> (http://www.freedesktop.org/software/systemd/man/sd-daemon.html)
> and
> call sd_notify(0, "READY=1"); / sd_notify(0, "STOPPING=1"); when
> starting / stopping
> (http://www.freedesktop.org/software/systemd/man/sd_notify.html).
> (with sd_notify READY=1, the shibd.service could use TimeoutStartSec=).

Yes, Type=notify would seem like a worthy goal.  It could be helpful
during reloads, too.  Socket activation, though, could potentially slow
down the first query too much to be generally useful.  Which is
unfortunate, because it's a useful concept.
-- 
Feri.