3

The documentation about Systemd's Inhibitor Locks and also man systemd-inhibit go to great length to explain how to start a process in a way as it blocks something (e.g. the handle-lid-switch event).

I was unable to find a way to allow me to remove such a "lock"/"inhibit"/"block".

Question: Is there a way to remove the systemd-inhibit lock, for instance via a dbus message?

Background: what would I need to remove a inhibitor lock for**

My Laptop has a laptop-lid close switch, which systemd-logind monitors and in case the lid is closed suspends the laptop - functionality "close-lid -> suspend".

Once the laptop is placed in its docking station, to make user of a bigger screen, Gnome's gsd-power arbitrarily ( and erroneously and without any available setting in Gnome to change it ) decides to create a inhibitor lock, preventing the functionality "close-lid -> suspend" to work.

Knowing how to remove an inhibitor lock, would allow me to remedy the erronous setting done by Gnome's gnome-setting-deamon power gsd-power. Gnome's setting is wrong, because manually invoking suspend systemctl suspend showed indeed no problem.

The inhibitor lock I would like to remove, as listed in systemd-inhibit --list is this:

     Who: alex (UID 1000/alex, PID 4248/gsd-power)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block
1

From the developer documentation of the inhibitor locks:

Inhibit() returns a single value, a file descriptor that encapsulates the lock. As soon as the file descriptor is closed (and all its duplicates) the lock is automatically released. If the client dies while the lock is taken the kernel automatically closes the file descriptor so that the lock is automatically released. A delay lock taken this way should be released ASAP on reception of PrepareForShutdown(true) (see below), but of course only after execution of the actions the application wanted to delay the operation for in the first place.

You probably don't want to kill gsd-power, so you would need to close the file descriptor that encapsulates the lock. It is most likely held by gsd-power. Forcing another process to close one of its file descriptors is not a normal thing to do, and might cause some side effects within gsd-power. But if you want to do it, read this question in Stack Overflow.

Instead, you might try removing gsd-power's permission to execute the DBus action org.freedesktop.login1.inhibit-handle-lid-switch. The man page dbus-daemon(1) might be helpful.

  • thank you for your answer and its quoted information. It is nice that some suggestions regarding the problem at hand gsd-powerwere included. However to comment upon then simply (1) you are mistaken if possible I "probably do want to kill gsd-power", as the culprit for this. (2) the suggestion to close another processes fd seems intriguing, but futile, I checked the source and gsd-power will continously interfere, not just only once. (3) Do you think dbus even capable of limiting access to logind's Inhibit method from gsd-power, I peaked into dbusdocu and it seems impossibe:( – humanityANDpeace Sep 14 '18 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.