[systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

[Lennart Poettering]

On Wed, 25.05.16 12:17, Michael Hirmke (mh at mike.franken.de) wrote:

> Hi *,
> 
> I'd like to write a script, which can listen to the PepareForSleep
> signal from systemd-logind. When it catches the signal, it should do a
> few things in the context of the user. While doing this, it should
> inhibit the sleep process. It gets started as autostart script in KDE.
> For this purpose I use perl and the module Net::DBus.
> Actually I am able to connect to the bus, attach to the appropriate
> signal and run something, when getting the signal.
> 
> But:
> 
> - I only can take delay locks. Whenever I try to take a *blocking* lock,
>   nothing happens, as if it is completely ignored. I don't get any
>   error message, though.
>   When using *delay* locks and the maximum inhibition time has been
>   exceeded, I get
> 
>   "systemd-logind: Delay lock is active (UID <uid>/<user>, PID
>   <pid>/dbus_logind) but inhibitor timeout is reached."
> 
>   So it seems to work in this case, but why not with blocking locks?

Note that for the root user and for normal users with access to the
local console blocking locks are advisory only. Also, locks taken by
programs running as the same user as the one attempting to shut down
are advisory only too. This policy may be configured differently via
PolicyKit however. Since most people probably don#t do this this boils
down to inhibitors being advisory-only for almost everybody, except if
you are on a true multi-user system, where locks taken by a user A are
non-advisory (i.e. "mandatory") for all users B with A != B if B does
not have access to the local console.

Being just advisory means that a user can shut down the system even if
a lock is taken, however, the lock is tracked and the expectation is
that the DE of your choice will still show them first, and ask for
confirmation to ignore them before you actually use your powers to
override them. GNOME does this, but I am not sure if your DE does it.

"systemctl poweroff" will show these locks in a similar way too, but
not for the root user.

> - I am not able to close the file descriptor in the pre block of the
>   signal handler. Whenever I try, I get an error, that the descriptor
>   is closed.

This suggests something else closed the fd for you?

Lennart

-- 
Lennart Poettering, Red Hat