Gnome logout dialog ignores inhibitors?

Desktop
#1

Hello,

I noticed that gnome session apparently seems to ignore all inhibitors at logout or shutdown.

I’m using Gnome 41.2 on Arch Linux. When I set up an inhibitor like this:

$ gnome-session-inhibit --app-id gnome-terminal.desktop --inhibit logout:suspend --reason 'Ongoing backup' cat

Then I see it in the list of inhibitors, both from gnome and from systemd, and as expected systemd refuses to shutdown:

$ gnome-session-inhibit --list
gnome-terminal.desktop: Ongoing backup (logout, suspend)
$ systemd-inhibit --list --no-pager
WHO            UID  USER  PID  COMM            WHAT                                                   WHY          MODE 
NetworkManager 0    root  545  NetworkManager  sleep                                                  NetworkMana… delay
UPower         0    root  690  upowerd         sleep                                                  Pause devic… delay
GNOME Shell    1000 basti 7104 gnome-shell     sleep                                                  GNOME muss … delay
basti          1000 basti 7265 gsd-media-keys  handle-power-key:handle-suspend-key:handle-hibernate-… GNOME handl… block
basti          1000 basti 7089 gnome-session-b shutdown:sleep                                         user sessio… block
basti          1000 basti 7265 gsd-media-keys  sleep                                                  GNOME handl… delay
basti          1000 basti 7266 gsd-power       sleep                                                  GNOME needs… delay

7 inhibitors listed.
$ systemctl halt
Operation inhibited by "basti" (PID 7089 "gnome-session-b", user basti), reason is "user session inhibited".
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl halt -i'.

However when I run gnome-session-quit or press the Logout button in the Gnome Shell menu I get the standard dialog, without any list of inhibitors, and I can press Logout and have my session ended or even my system powered off without even being warned about the existing inhibitor.

Is this intended behaviour? If so how can I make Gnome Shell respect inhibitors?

#2

how can I make Gnome Shell respect inhibitors?

Specify a valid app id, like org.gnome.Terminal.desktop. gnome-shell ignores inhibitors it cannot match to actual applications.

#3

Oh :flushed:

So gnome shell silently ignores inhibitors without a matching app, and also all inhibitors set directly at systemd level with systemd-inhibit? That’s quite a surprise :hushed:

I’ll try this but I’m a bit unhappy about this behaviour. After all this means that gnome shell can silently interrupted important processes without any warning :thinking:

What’s the rationale behind this behaviour?

Is there some kind of flag to make gnome shell respect all inhibitors? Or, perhaps as an alternative, do you know a flag to make systemd prohibit shutdown by gnome shell if inhibitors are in place?

PS: This behaviour isn’t documented in the manpage of gnome-shell-inhibit. Would you consider a merge request which fixes this?

#4

Apps are something we can present to the user, random process aren’t really.

We could show something like

if the design team agrees.

and also all inhibitors set directly at systemd level with systemd-inhibit

Those aren’t ignored, they aren’t supported at all. Systemd’s inhibitors are more low-level, and while gnome-session’s inhibitor predate systemd, they nowadays use them underneath.

Unless you can convince gnome-session maintainers to replace the session inhibitor API (or more likely given compatibility concerns: Turn it into a mere front-end of systemd inhibitors), that’s not going to change.

and also all inhibitors set directly at systemd level with systemd-inhibit

No.

Or, perhaps as an alternative, do you know a flag to make systemd prohibit shutdown by gnome shell if inhibitors are in place?

I’m a bit surprised that it doesn’t work like that. In the end, shutdown is implemented by gnome-session calling logind’s PowerOff method. You’d assume that logind respects its own inhibitors :thinking:

This behaviour isn’t documented in the manpage of gnome-shell-inhibit . Would you consider a merge request which fixes this?

gnome-session-inhibit is part of gnome-session, not gnome-shell. I’m not a maintainer there, so it’s not for me to consider MRs.

#5

Inhibiting shutdown using systemd-inhibit actually works for me, I get this prompt when I try to power off after using it:

Screenshot from 2022-01-10 17-57-23

The message here is technically coming from logind’s polkit rules. It could be better and show the inhibitor’s description but not sure if there is a way to retrieve that from logind in a race-free way.

#6

First of all, thanks a lot @fmuellner; adding an existing app ID works perfectly. Much obliged for the quick help :pray:

I understand. Still, when approaching this from the manpage of gnome-session-inhibit it’s somewhat surprising because the manpage doesn’t document this restriction, and gnome-session-inhibit doesn’t warn.

It’s also surprising that gnome-session-inhibit allows me specify a non-existing app or even omit the --app-id argument entirely. What’s the purpose of inhibitors without existing apps if they don’t get shown and don’t block logout? Are they just a frontend to systemd-inhibit? At least such inhibitors appear in systemd-inhibit --list.

So was I :see_no_evil:

Could this be polkit perhaps? At least @jfrancis says the message comes from polkit.

My user account is in wheel, and my distro’s polkit config makes wheel an admin wrt to polkit, so perhaps admin accounts can bypass inhibitors during shutdown?

This at least would be consistent within systemd, because sudo systemctl halt also ignores inhibitors when invoked non-interactively (unless you explicitly pass --check-inhibitors=yes).

Do you happen to know how I could check this? How do I debug polkit?

1 Like
#7

It’s not wheel; an unprivileged user account can also shutdown the system “against” their own inhibitors :confused:

I must admit that I don’t really understand how systemd inhibitors work :man_shrugging: but given that the gnome session inhibitor works now I don’t really care much anymore :slightly_smiling_face: