Hi, > In the face of the race condition with systemd unit files, reported > by Michael Biebl, there seem to exist different alternatives. > > > > Lennart Poettering: > https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=744753#40 > "a service which needs to be restarted on > cases like this sounds wrong. Thats a hack really. The service should > just watch time changes and react correctly to that. i.e. use > TFD_TIMER_CANCEL_ON_SET. THis will report wallclock changes relative to > monotonic time, which is what you want to watch for this. All system > resumes will trigger this, of course." > > and > > "Since a long time we had on our TODO list to support timer units that > are triggered when the system clock changes, based on > TFD_TIMER_CANCEL_ON_SET. Hasn't been implemented yet, should be fairly > easy though." > > "OnClockChange=yes"
This does not sound to me like it applies to hdparm. We are not caring about the clock here, we are caring about devices re-appearing after suspend-resume and hence needing reconfiguration. > > And in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780956 > the dev showed that udev already has proper hooks for resume events. > > So these may be proper mechanisms for packages to ship with a > resume hook. And the last one is already tried and proven by > laptop-mode-tools. Looking through the report you linked, it seems the laptop-mode-tools hook is actually unreliable when using asynchronous suspens/resume power management, which is the default (?) on newer kernels. So that doesn't really sound like a "proper" mechanism. I agree though that udev is probably the right place to fix this. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
