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/:
[ "$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.
*** Bug 50568 has been marked as a duplicate of this bug. ***
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.
Created attachment 63961 [details] [review]
Here is a (largely untested) implementation.
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.
(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.