systemd restart service on resume

[Greg Woods]

On Sun, 2013-12-08 at 18:22 +0100, Heinz Diehl wrote:
> On 08.12.2013, Greg Woods wrote: 
> 
> > I am trying to find a way to get a service to restart when the system is
> > resumed from suspend or hibernation.
> 
> You can place a script in /usr/lib/systemd/system-sleep 

Thanks for the tip on that. I now remember that I had tried this before
and it didn't work. I played with this for a couple of hours today, and
discovered that the reason it didn't work is that you can't call
"systemctl" from this script. In retrospect I should have realized this,
because this script runs while systemd is busy changing states and it is
executing things in a tree, and running "systemctl" is like suddenly
lopping off a branch to that tree (or adding a new one), and this will
have unpredictable results.

This comes from me still thinking about things in the old way. To use
systemd, you have to think in terms of how systemd works, not in terms
of how the old init scripts work. 

It was bizarre; when I had a "systemctl restart racoon" command in my
system-sleep script, what would happen is that suspend would hang,
issuing a long single beep about every 25 seconds or so. After a couple
of minutes, it would finally suspend. On resume, it would just keep
single-beeping every 25 seconds forever; it would never come back from
suspend. This was 100% reproducible; put the systemctl command in the
script, it goes into "beep mode". Take it out, and suspend works
normally again.

What finally worked was to change the service definition for the racoon
service to automatically restart it when the daemon died, then insert
commands into the system-sleep script to explicitly kill the daemon on
suspend or hibernate. On resume, systemd notices that the daemon is gone
and restarts it (I don't try to restart it in the system-sleep script; I
first tried that and wound up with two copies of the daemon running). So
I end up with just a "killall racoon" command in the system-sleep
script, and setting Restart=always in the service file.

--Greg