Am 03.04.2014 16:03, schrieb Michael Biebl: > I think the way to address is, is to make systemd-logind not send out > the "Suspending" D-Bus signal when there is no way the suspend request > will be processed. > > My immediate idea was to stick a sd_booted() check into logind, but > unfortunately it's not quite as simple. With systemd-shim around, such a > suspend request can actually work for PID 1 != systemd as it would be > handled by the systemd-shim process (which is D-Bus activated on-demand). > > So we probably need a different approach, like logind doing a D-Bus Ping > to the org.freedesktop.systemd1 interface to see if there would be > process handling the suspend/hibernate request.
If you look at org.freedesktop.login1.Manager's D-Bus interface, at least the following methods rely on systemd = PID1 (or systemd-shim): PowerOff Reboot Hibernate HybridSleep Suspend If those methods are called, logind in turn will try to activate the corresponding targets in systemd, like suspend.target, hibernate.target via org.freedesktop.systemd1.Manager StartUnit() See e.g. src/login/logind-dbus.c execute_shutdown_or_sleep() If we could enforce that either systemd-sysv or systemd-shim is installed, this would make things simpler, since we could assume org.freedesktop.systemd1.Manager to be present. (in case of systemd-sysv after a reboot, at least). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
