|Summary:||Please hookup suspend/resume code of upower with systemd|
|Product:||upower||Reporter:||Lennart Poettering <lennart>|
|Component:||general||Assignee:||Richard Hughes <richard>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
Description Lennart Poettering 2012-06-21 09:09:22 UTC
It would be great if the system suspend/resume code could get a minimal hookup with systemd. Here's what I'd like to see: a) The Suspend() bus call should execute the equivalent of the following command to trigger a suspend via systemd, rather than pm-suspend: dbus-send --system --dest=org.freedesktop.login1 --type=method_call /org/freedesktop/login1 org.freedesktop.login1.Manager.Suspend boolean:true b) Similar Hibernate() should execute the equivalent of the following: dbus-send --system --dest=org.freedesktop.login1 --type=method_call /org/freedesktop/login1 org.freedesktop.login1.Manager.Hibernate boolean:true c) to get notification about resumes, please drop a small hook script into /usr/lib/systemd/system-sleep/: #!/bin/sh [ "$1" = "post" ] && exec /usr/bin/dbus-send --system --dest=org.freedesktop.UPower --type=signal /org/freedesktop/UPower org.freedesktop.UPower.Resuming This would simply send the same message to upower that upower should then broadcast to the bus. Upower should listen to this message and react accordingly. And that should be all for the minimal hookup. I hope this makes sense.
Comment 1 Matthias Clasen 2012-07-05 18:35:56 UTC
*** Bug 50568 has been marked as a duplicate of this bug. ***
Comment 2 Matthias Clasen 2012-07-07 17:04:37 UTC
The way the upower code is currently structured, this is unfortunately not entirely trivial. upowers Sleep method does not actually return until resume time - ie we are inside a method call when we have to wait for the 'Resuming' signal. And the backend abstraction in upower consists of commandline strings that the daemon frontend spawns, and the suspend/hibernate commands are assumed to not return until resume time.
Comment 3 Matthias Clasen 2012-07-07 19:40:28 UTC
Created attachment 63961 [details] [review] prototype Here is a (largely untested) implementation.
Comment 4 Matthias Clasen 2012-07-07 19:48:26 UTC
Note that the patch only listens for resume from systemd if it triggered the sleep itself. That should possibly be changed to keep the signal handler installed, always, so that emit Resuming even if the sleep has not been initiated by upower. That would allow consumers of Resuming like NM continue to just use the upower signal.
Comment 5 Richard Hughes 2012-07-11 17:14:34 UTC
(In reply to comment #2) > And the backend abstraction in upower consists of commandline strings that the > daemon frontend spawns Yes, non-ideal. I'll rework this when I have time to port it to gdbus. I've fixed up and tested your patch and pushed it master, many thanks.