Systemd: systemctl: add option to make inhibitors fatal even when running non-interactively and when run with the necessary privs

Created on 21 Feb 2016  ·  2Comments  ·  Source: systemd/systemd

Today I was playing with inhibitor locks. I can create one of those running this in a terminal:

systemd-inhibit bash

While I leave that bash process open, shutdown will presumably be inhibited. Indeed, if I open other terminal and type systemctl poweroff I will get this informative message:

Operation inhibited by "bash" (PID 2013 "systemd-inhibit", user ntrrgc), reason is "Unknown reason".
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl poweroff -i'.

Next, I wanted to show the error message it in a GUI instead, so I instructed bash to pipe and store the output of systemctl poweroff, like this:

output=$(systemctl poweroff 2>&1)

Then, suddenly, the computer shut down.

I tried calling it in many ways, but there was a constant: If systemctl's stdout was not a tty it always ignored any inhibitor locks. It did not matter it was piped to bash, to /dev/null or was running in a GUI outside of the terminal, in any case it did shutdown disregarding the locks. The locks where respected only when stdout was a virtual terminal.

Why does this happen? Can it be avoided?

RFE 🎁 systemctl

Most helpful comment

Thanks for the explanation.

That's a bit unfortunate for use cases like this. Isn't there a way to tell systemctl to obey inhibitors anyway? Maybe it should be included in https://github.com/systemd/systemd/issues/949?

By the way, I could not find that behavior documented anywhere. I searched in man systemctl and found a --ignore-inhibitors switch but it does not specify it being a default for non-interactive executions.

All 2 comments

if you have the priviliges to ignore inhibitors, then you can shutdown even if there's an inhibitor in place.

In order not to break scripts inhibitors are not shown if systemctl is called non-interactively – if the scripts has the priviliges to ignore the inhibitors. That's what you are seeing here.

This is expected behaviour hence.

Thanks for the explanation.

That's a bit unfortunate for use cases like this. Isn't there a way to tell systemctl to obey inhibitors anyway? Maybe it should be included in https://github.com/systemd/systemd/issues/949?

By the way, I could not find that behavior documented anywhere. I searched in man systemctl and found a --ignore-inhibitors switch but it does not specify it being a default for non-interactive executions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

brianjmurrell picture brianjmurrell  ·  3Comments

flokli picture flokli  ·  3Comments

anitazha picture anitazha  ·  3Comments

nontrinaryalternativeblackmale picture nontrinaryalternativeblackmale  ·  3Comments

okdana picture okdana  ·  3Comments