shibboleth SP on RHEL7 not fully starting. Systemd stuck in a loop

Scott that's great and it's the road I've ended up coming on too:

1. Create a directory called shibd.service.d in /etc/systemd/system
2. Created a file in /etc/systemd/system/shibd.service.d called timeout.conf with the following contents:
[Service]
TimeoutStartSec=180s
3. Refresh systemd with a systemd daemon-reload and (re)start shibd using systemctl.

I think we're all getting to grips with systemd slowly but surely (I've certainly learned more about it myself) since I originally submitted this bug and now understand why both editing the existing unit file and "forking it" with a separate unit file in /etc/systemd/system are inadvisable

Placeholder docs added to https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxSystemd

dccaa94e400ddfdccf231eec290de724447bc7c6

I increased the wait time to 150 seconds via the RPM specfile, which doesn't affect startup time in general. I could probably just increase it more.

I did some research and systemd isn't meant to rely on /etc/sysconfig

Per [1], the new way you do this is by overriding specific Unit file lines in a directory created by the deployer, which is similar to what I suggested, but avoids having to copy the whole file and maintain it.

It's a documentation thing and I'll have to write something up.

[1] http://serverfault.com/questions/413397/how-to-set-environment-variable-in-systemd-service

OK thanks for confirming the behaviour re: the unit files. It sounds like we have a reasonable workaround in:
1. Copy existing unit file to /etc/systemd/system
2 systemctl disable shibd and systemctl enable shibd to re-create the symlinks.
3 (Optional) restart shibd.
I'll implement this and leave the sysconfig suggestion "out there" as a feature request.

The copy from the RPM is explicitly read only, and you're meant to create your version in /etc to override it. So, yes, the RPM will absolutely replace it, and I'm required to in fact. Your version will take precedence and will be safe.

That said, not disagreeing with the other suggestion, just wanted to note that the workaround for this is already built in to systemd.