On Tuesday 24 March 2015 01:36 PM, Ondřej Grover wrote: > Hello, > > I enabled the service and restarted the laptop, it was started as > expected, but not restarted after suspending, which results in APM > levels to not be restored as I feared. However, sometimes it is not > reset (or at least that's what I think is happening). > I am willing to test a deb package, assuming it will be reasonably > safe and I will understand the changes. >
That it should. We leverage the "trigger on resume" mechanism from udev, not systemd. So either udev got screwed up recently (which I doubt) or else something is overriding the changes. > I was thinking about how to solve this. After reading through manpages > (systemd-suspend.service(8), systemd.special(8), systemd.unit(8)) I > came up with this possible solution, but it's not working: > > Create a file /etc/systemd/system/laptop-mode.service.d/sleep.conf > with the following overrides: > > [Unit] > Conflicts=sleep.target > > Rationale: > > As per systemd.special(8): > > sleep.target > A special target unit that is pulled in by suspend.target, > hibernate.target and hybrid-sleep.target and may be used to hook units > into the sleep > state logic. > > And from systemd.unit(8) > > Conflicts= > A space-separated list of unit names. Configures negative > requirement dependencies. If a unit has a Conflicts= setting on > another unit, starting > the former will stop the latter and vice versa. Note that > this setting is independent of and orthogonal to the After= and > Before= ordering > dependencies. > > So this means that before systemd goes into suspend or hybrid state > which is signaled by the sleep.target unit, the laptop-mode.service > unit should stop and when the sleep.target unit is stopped after > resuming, the laptop-mode.service should be restarted. However, a unit > that was stopped because of this is not automatically restarted as > people in šsystemd on Freenode explained to me. > > As is stated in systemd-sleep(8): > > Immediately before entering system suspend and/or hibernation > systemd-suspend.service (and the other mentioned units, respectively) > will run all > executables in /lib/systemd/system-sleep/ and pass two > arguments to them. The first argument will be "pre", the second either > "suspend", > "hibernate", or "hybrid-sleep" depending on the chosen action. > Immediately after leaving system suspend and/or hibernation the same > executables are > run, but the first argument is now "post". All executables in > this directory are executed in parallel, and execution of the action > is not continued > until all executables have finished. > > Note that scripts or binaries dropped in > /lib/systemd/system-sleep/ are intended for local use only and should > be considered hacks. If applications > want to be notified of system suspend/hibernation and resume, > there are much nicer interfaces available. > > However, the people in #systemd explained to me that by "nicer > interfaces" DBus is meant, which is not easily applicable for > laptop-mode-tools. > > A possible system-wide solution was proposed in > https://bugs.debian.org/779370 where a systemd unit would trigger a > udev change that might trigger some of the rules in > /lib/udev/rules.d/99-laptop-mode.rules > So I'm confused here. Earlier, the kernel emitted an event and we trapped it using udev. Does that not happen any more? I ask because, on my laptop, it still works that way. And I do have systemd installed. > Another system-wide solution I would like to propose (but it still > doesn't work for me) is to put a file in > /lib/systemd/system-sleep/power-hook which would support the hooks in > /usr/lib/pm-utils/sleep.d/ , including > /usr/lib/pm-utils/sleep.d/01laptop-mode > See the attached file. > This I deprecated long back, the day the pm-utils devs started making pm-utils conflict with laptop-mode-tools. That was when we moved to an event based model, relying only on udev. With systemd in, I think don't think udev has been broken. Or its event tracking ability changed. Is it ? > However, neither of these work reliably. Sometimes it is set to 128 > after suspend, sometimes it remains at 254 (or is set as expected, I'm > not sure). It almost looks like it's some kind of race issue, but I > wasn't able to find anything relevant with '128' in /etc or /lib. > From what you've explained, to me, it looks more like someone else too is fiddling with the settings. To confirm if LMT acted on resume, can you please leverage the exec-commands module. Just cat some file on resume. That'll prove if LMT was triggered on resume. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
