[systemd-devel] systemd and LSB Required/Should-Stop

[Ville Skyttä]

On 06/27/2011 04:18 PM, Lennart Poettering wrote:
> On Fri, 24.06.11 14:04, Ville Skyttä (ville.skytta at iki.fi) wrote:
> 
>> Hello,
>>
>> Am I right that systemd does currently have no support for the LSB
>> Required-Stop and Should-Stop keywords?  If yes, are there plans to
>> support them in the future?
> 
> That is true, we do not support this right now. In systemd the shutdown
> order is always the inverse startup order of two services. I am not
> entirely opposed to make this more flexible but so far I have not heard
> of a good usecase where the flexibility to detach the shutdown oder from
> the startup order was necessary. 

I don't know if this is a good argument or not, but for now I don't know
what to add as a start dependency to get stuff run before hwclock does
its stuff at shutdown.  $time?  hwclock-save?  Something else?

>> The use case I have is in Fedora's vdr package:
>> http://pkgs.fedoraproject.org/gitweb/?p=vdr.git .  The init script's
>> stop action uses rtcwake to set the next wakeup time for the box, and
>> even though the implementation is hairier than I'd like, it has worked
>> well for me before Fedora 15.  But with Fedora 15 and systemd it often
>> fails to do its job when shutting down the system (works fine if I just
>> stop vdr with the machine running), which causes my PVR box not to wake
>> up when it should and consequently missed timed recordings which is very
>> annoying.
>>
>> The way the init script's stop action handles setting the wakeup time is
>> that it looks up the time to set from the /var/run/vdr/next-timer file
>> which may or may not be present; if it's not, it grabs the time using
>> SVDRP (a simple TCP based protocol) from localhost, and finally if it
>> gets the time from one of these sources, writes it to the RTC with
>> rtcwake.
> 
> Is there any good reason why this isn't stored in the RTC right-away,
> when needed? It sounds unnecessarily complex and fragile to delay this
> until shutdown.

Yes, see "hairier than I'd like" above and "some thoughts about "fixing"
vdr", and "for now there's nothing" below quoted from my original mail.
 It boils down to 1) the code doesn't exist yet, 2) I'm not really a
C(++) coder so implementing it might take a while (duplicate rtcwake
code? the daemon starts up as root but drops privileges -> libcap? needs
to be pluggable because some systems don't work with rtcwake (dunno
about CLOCK_REALTIME_ALARM) but require other nonstandard tools) etc,
and 3) I have a hunch that such a "fix" might end up needing to be
maintained outside of upstream vdr as a patch or a plugin which given 2)
doesn't sound that nice.

> Also, much simpler and nicer would be to use CLOCK_REALTIME_ALARM which
> allows multiple clients to trigger a wakeup from suspend.
> 
>> I've done some debugging and when rtcwake fails, it fails because
>> /dev/rtc0 is being handled by /sbin/hwclock (hwclock-save.service).  So
>> my first thought was to add "hwclock-save" to the init script's
>> Should-Stop LSB keyword but that didn't help, so I grepped systemd's
>> sources for Should-Stop and found nothing.
> 
> We have now removed this unit file in git. However can you elaborate why
> exactly these two service conflict when run at the same time? do you
> have any error messages?

I don't have the exact one at hand now, but if I remember correctly, it
was "/dev/rtc0: device or resource busy" and according to fuser, hwclock
was the thing reserving /dev/rtc0 thus causing rtcwake to fail.

>> I have some thoughts about "fixing" vdr to implement the wakeup time
>> stuff better than it does now sometime in the future, but for now
>> there's nothing.  Ideas for hacks/workarounds for the init script (see
>> above for the gitweb link) I could use to make sure that /var/run and
>> localhost networking are available at the time vdr gets stopped at
>> shutdown, and that nothing's reserving /dev/rtc0 at that time (so I
>> suppose $local_fs, $network, and $time/hwclock-save haven't been
>> "stopped" yet)?  Note that I'm stuck with the sysv vdr init script until
>> Fedora 16 (can't convert the package to native systemd before that).
> 
> If a service A and a service B are ordered against each other
> (regardless in which way) then systemd will ensure that when one is
> started and the other is stopped, the stopping is done first and the
> starting second. That means you can just add any kind of ordering dep
> between the two, and things should work.

That's what I've understood, but what I don't know at the moment what to
add to vdr's "Should-Start" so that it doesn't cause problems at
startup, and ends up running before hwclock-save at shutdown.  Simply
hwclock-save, even if it shouldn't be run at startup at all?  And as you
mentioned, the hwclock-save unit file has been removed in git, does
something else replace what it was doing or fiddle with the RTC
otherwise, or was the feature dropped altogether and I can use
hwclock-save in Should-Start now and not worry about the time when a
systemd that doesn't have it lands in Fedora?

Another thing I might be missing is some kind of a command from which I
could get an easy to read listing of what exactly gets run in which
order at shutdown.