How do remove a systemd-inhibit block

gnomesuspendsystemd

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

Best Answer

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.

Using a system service:

Create the file /etc/systemd/system/my_user_script.service:

[Unit]
Description=Run my_user_script
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target


[Service]
ExecStart=/path/to/my_user_script
#User=my_user_name
#Environment=DISPLAY=:0

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

Remove suspend/hibernate/hybrid in case the service should only be executed after waking up from a specific type of sleep. In case the service needs to be run by a specific user, uncomment the User= and Environment= lines and replace the relevant user name.

Install the service file with:

sudo systemctl enable my_user_script

Using a user service will not work:

In order to avoid setting a hard coded user name with User=, one could create the exact same service file at ~/.config/systemd/user/my_user_script.service and activate with

systemctl --user enable my_user_script

However, that will not work. @grawity explains in more detail at unix.stackexchange.com/a/174837/163108 why that is:

sleep.target is specific to system services. The reason is, sleep.target is not a magic target that automatically gets activated when going to sleep. It's just a regular target that puts the system to sleep – so the 'user' instances of course won't have an equivalent. (And unfortunately the 'user' instances currently have no way to depend on systemwide services.)

Writing systemd unit file for suspend/resume

You've confused what After is referring to, After will cause a service to wait for another unit before it starts. Your Wanted-By=suspend.target and After=suspend.target contradict each other.

The Wanted-By is stating that bt-mouse-resume.service is a part of suspend.target, but the After is stating that bt-mouse-resume.service should wait until suspend.target is done. Services should not be a part of a target and wait for that target before starting. This also means you're configuring your service to run when suspend.target is started, rather than when it is exited.

What you're really looking for is a way to run something when stopping suspend.target, so I'll point you to a pretty important part of systemd:

Note that when two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied.

Reference

So you say your bt-mouse-suspend.service is working properly. Because of its Wanted-By=sleep.target, when sleep.target is started your service is run. Conversely, when sleep.target is stopped bt-mouse-suspend.service will be stopped as well. You should not require the Before field in this service, you are making your service an action of that target already.

So if you want to run /usr/bin/hciattach -s 152000 /dev/ttyS1 billionton when leaving sleep.target, make it the ExecStop for bt-mouse-suspend.service.

I'd also recommend some further reading on how systemd works, namely take a look at:

https://www.freedesktop.org/software/systemd/man/systemd.service.html#

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#

https://www.freedesktop.org/software/systemd/man/systemd.target.html#

Also, your two services target suspend.target and sleep.target. You should obviously use whichever target you're actually concerned with, but you're probably only looking for suspend.target.

Best Answer

Related Solutions

How to run a user script after systemd wakeup

Using a system service:

Using a user service will not work:

Writing systemd unit file for suspend/resume

Related Question