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

[Lennart Poettering]

On Tue, 28.06.11 12:54, Ville Skyttä (ville.skytta at iki.fi) wrote:

> 
> 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?

Order against hwclock-save.service. That should do the job for you. Just
stick Before=hwclock-save.service in your service file if it is native,
or Should-Start=hwclock-save if it is SysV.

> >> 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.

CLOCK_REALTIME_ALARM should simplify most things, as you don't need to
deal with any low-level intricacies of rtcwake, and just can use a
normal timer that happens to wake up the system when it elapses when the
system is suspended.

> > 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.

Oh, that would mean that /dev/rtc0 can only have a single opener at a
time? 

Indeed, just verified this. How ugly. CLOCK_REALTIME_ALARM FTW!

> > 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?  

Yes.

> 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?

In systemd git (and soon on Rawhide/F16) we do not fiddle with the RTC
at all anymore at shutdown. Instead we want everybody to sync time
changes directly down to the RTC and if NTP is used the kernel does that
anyway. Hence your service will be the only user (well, unless some
other services decides to use the RTC too. You guys should really use
CLOCK_REALTIME_ALARM which allows multiple consumers of the logic).

> 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.

Well, there's "systemctl plot", but that's admittedly not very readable
for a somewhat real-life OS.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.