[Bug 1157122] Re: PrepareFor{Sleep, Shutdown} (false) signals not emitted

[Martin Pitt]

Thanks! I simplified the patch a bit to avoid moving the whole function
(I just added a forward declaration) and another "ret" variable, but the
spirit of it works very well. Tested with

  sudo dbus-monitor --system
"type='signal',sender='org.freedesktop.login1',interface='org.freedesktop.login1.Manager'"

and

  gdbus call --system --dest org.freedesktop.login1 --object-path
/org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend false

** Changed in: systemd (Ubuntu)
       Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1157122

Title:
  PrepareFor{Sleep,Shutdown} (false) signals not emitted

Status in “systemd” package in Ubuntu:
  Fix Committed

Bug description:
  Per

    http://www.freedesktop.org/wiki/Software/systemd/inhibit

  "PrepareForShutdown(false) may be subscribed to by applications which
  want to be notified about system resume events. Note that this will
  only be sent out for suspend/resume cycles done via logind, i.e.
  generally only for high-level user-induced suspend cycles, and not
  automatic, low-level kernel induced ones which might exist on certain
  devices with more aggressive power management. "

  (I think it means s/Shutdown/Sleep in the first sentence)

  Our systemd has a patch 0016-Add-poweroff-reboot-suspend-hibernate-
  fallback.patch which calls the executables from pm-utils in the case
  that the systemd D-Bus API isn't available (which is the case for us).
  Usually, logind calls shutdown/suspend/... methods via systemd jobs.
  In our case, since we call these executables directly, the jobs aren't
  used and so the standard systemd Job* signals aren't sent. It's these
  signals that logind listens for to know when to emit the
  PrepareFor{Sleep,Shutdown} (false) signals.

  I attach a strawman patch (diff of a diff - look at it after applying)
  which explicitly sends the signal and does some other needed cleanups
  (see bus_message_filter for the call site for where the signal is
  usually sent). Let me know what you think.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1157122/+subscriptions