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?
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. 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. 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). _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
