GNOME Bugzilla – Bug 677694
optionally listen to systemd for sleeping/resuming notification
Last modified: 2012-10-13 14:17:56 UTC
When suspend/resume are done using systemd, the upower signals never come. Here is a proof-of-concept patch. Is build-time decision between upower or systemd good enough for you ? One could imagine writing a NmSleepMonitor implementation that monitors both systemd and upower, but that would be a bit more messy than the current approach. Also, I couldn't figure out fd-passing with dbus-glib, so I've left the GDBus code in here. Maybe you know how do to this with dbus-glib ?
Created attachment 215930 [details] [review] factor out sleep monitor
Created attachment 215931 [details] [review] systemd sleep monitor implementation
Review of attachment 215931 [details] [review]: ::: src/nm-sleep-monitor-systemd.c @@ +77,3 @@ + GUnixFDList *fd_list; + + res = g_dbus_proxy_call_with_unix_fd_list_finish (sd_proxy, &fd_list, result, &error); Comments from davidz: res is the index in the fd_list, should actually use it like that. Ie its type will be (h)
I'd like to table this until Lennart gets back from hiking and can explain a bit why he designed the API with fd passing instead of just D-Bus methods and tracking when clients fall off the bus to clear their inhibitor. Thanks for the patches though, to be continued...
Using timerfd_create() for a year ahead is kind of gross. It will work, and if the goal here is to drop upower, then I think it's an OK intermediate step. However, what we really want is to be event-driven, and schedule wakeups only for when we need to wake up. This gets us into the question: Why exactly does NM need to be notified when the system resumes? Looking at do_sleep_wake(), /* Ensure rfkill state is up-to-date since we don't respond to state * changes during sleep. */ nm_manager_rfkill_update (self, RFKILL_TYPE_UNKNOWN); Seems like this kind of thing the kernel should be fixed to check device state on resume and send out uevents? I mean, it will send out events if a device got unplugged while suspended, right? Why not check rfkill state too? Then there's a lot that happens in nm_manager_update_state()...I can't say. But I think the point stands here that the long term fix is to be driven by individual events, rather than trying to handle some global system suspend/resume event.
Alternatively, nm could install a script in /usr/lib/systemd/system-sleep like the one discussed in https://bugs.freedesktop.org/show_bug.cgi?id=51305 and get resume notification that way.
Created attachment 226098 [details] [review] factor out sleep monitor
Created attachment 226099 [details] [review] add a systemd sleep monitor
New patches; simplified: no more timerfd, instead we rely on the before/after emissions of PrepareForSleep. See http://www.freedesktop.org/wiki/Software/systemd/inhibit
Patches look good except for code style issues (indentation and {} on same line as if/else). But I can fix that up when applying I suppose.
Pushed as: 64fd8eea7706038e5d38c8463a1c765ed9331db2 ea0c3a3e0fcbe400a704692d3b436d4733d348a1 Thanks!