3

Problem

On Debian 12 I use IdleAction=poweroff and IdleActionSec=… in logind.conf. This works as intended, the machine powers itself off when it's been idle for long enough.

I want to be able to use systemd-inhibit --what=idle as a regular user. I have found claims that it should be possible (example). Indeed, in one of my Debian 12 systems it is possible, let's call this Debian Successful; but there are other Debian 12 systems where I get Access denied, let's call these Failing. The machine where I really need this functionality is in the Failing group.

It's not a temporary quirk (because of "needing to reboot" or something). I have just rebooted the Successful machine and one Failing, the behavior persists.

Why the difference? What can I do to make a Failing system behave like the Successful one?

I'm not really interested in workarounds like sudo or some custom wrapper. I'd like systemd-inhibit --what=idle to "just work", like it does on the Successful system. I'd like to adjust its behavior as much "by the systemd/polkit book" as possible.

Current behavior

This is how it works on the Successful system. This is what I want:

$ SYSTEMD_LOG_LEVEL=7 systemd-inhibit --what=idle true
Bus n/a: changing state UNSET → OPENING
sd-bus: starting bus by connecting to /run/dbus/system_bus_socket...
Bus n/a: changing state OPENING → AUTHENTICATING
Bus n/a: changing state AUTHENTICATING → HELLO
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.75 path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s error-name=n/a error-message=n/a
Bus n/a: changing state HELLO → RUNNING
Sent message type=method_call sender=n/a destination=org.freedesktop.login1 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=Inhibit cookie=2 reply_cookie=0 signature=ssss error-name=n/a error-message=n/a
Got message type=method_return sender=:1.7 destination=:1.75 path=n/a interface=n/a member=n/a cookie=149 reply_cookie=2 signature=h error-name=n/a error-message=n/a
Successfully forked off '(inhibit)' as PID 3384.
Skipping PR_SET_MM, as we don't have privileges.
true succeeded.
Bus n/a: changing state RUNNING → CLOSED
$ echo $?
0
$

This is how it fails on the Failing systems:

$ SYSTEMD_LOG_LEVEL=7 systemd-inhibit true
Bus n/a: changing state UNSET → OPENING
sd-bus: starting bus by connecting to /run/dbus/system_bus_socket...
Bus n/a: changing state OPENING → AUTHENTICATING
Bus n/a: changing state AUTHENTICATING → HELLO
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.44 path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s error-name=n/a error-message=n/a
Bus n/a: changing state HELLO → RUNNING
Sent message type=method_call sender=n/a destination=org.freedesktop.login1 path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=Inhibit cookie=2 reply_cookie=0 signature=ssss error-name=n/a error-message=n/a
Got message type=error sender=:1.1 destination=:1.44 path=n/a interface=n/a member=n/a cookie=464 reply_cookie=2 signature=s error-name=org.freedesktop.DBus.Error.AccessDenied error-message=Permission denied
Failed to inhibit: Access denied
Bus n/a: changing state RUNNING → CLOSED
$ echo $?
1
$

true is just an example. Ultimately I want to invoke some long-running command for which inhibiting makes perfect sense.

Details

  • Successful and Failing are Debian 12.

  • The kernel on Successful and on each Failing is 6.1.0-17-amd64.

  • The output of id:

    @Successful $ id
uid=1000(kamil) gid=1000(kamil) groups=1000(kamil),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev),111(bluetooth),113(lpadmin),117(scanner),124(pcspkr)

    @Failing1 $ id
uid=1000(kamil) gid=1000(kamil) groups=1000(kamil),4(adm),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev)

  • On each system /usr/bin/systemd-inhibit gives the same md5sum, I conclude the files are identical between Successful and Failing; they have not been tampered with. ls -l /usr/bin/systemd-inhibit prints:

    -rwxr-xr-x 1 root root 22928 11-10 01:25 /usr/bin/systemd-inhibit

  • On each system /usr/share/dbus-1/system.d/org.freedesktop.login1.conf gives the same md5sum, I conclude the files are identical between Successful and Failing; they have not been tampered with. The relevant(?) parts:

    <busconfig>

      <policy user="root">
              <allow own="org.freedesktop.login1"/>
              <allow send_destination="org.freedesktop.login1"/>
              <allow receive_sender="org.freedesktop.login1"/>
      </policy>

      <policy context="default">
              <deny send_destination="org.freedesktop.login1"/>
[...]
              <allow send_destination="org.freedesktop.login1"
                     send_interface="org.freedesktop.login1.Manager"
                     send_member="Inhibit"/>
[...]
              <allow receive_sender="org.freedesktop.login1"/>
      </policy>

</busconfig>

  • On each system /usr/share/polkit-1/actions/org.freedesktop.login1.policy gives the same md5sum, I conclude the files are identical between Successful and Failing; they have not been tampered with. The relevant(?) parts:

    <policyconfig>
[...]
      <action id="org.freedesktop.login1.inhibit-block-idle">
              <description gettext-domain="systemd">Allow applications to inhibit automatic system suspend</description>
              <message gettext-domain="systemd">Authentication is required for an application to inhibit automatic system suspend.</message>
              <defaults>
                      <allow_any>yes</allow_any>
                      <allow_inactive>yes</allow_inactive>
                      <allow_active>yes</allow_active>
              </defaults>
      </action>
[...]
</policyconfig>

    I guess this <allow_any>yes</allow_any> is responsible for the alleged ability of a regular user to use systemd-inhibit --what=idle. Still on Failing systems it seems to be ignored.

  • The Successful Debian uses its hardware directly. One Failing Debian is installed on HP ProLiant DL380 G5; other Failing Debians are virtual machines in VMware ESXi 7.

  • I use ssh to connect to the Successful system and to each Failing one. The Successful system provides a GUI but it's "just in case"; currently sddm only sits there and I don't log in this way.

  • The output of pstree -lu:

    @Successful $ pstree -lu
systemd-+-ModemManager---2*[{ModemManager}]
        |-NetworkManager---2*[{NetworkManager}]
        |-accounts-daemon---2*[{accounts-daemon}]
        |-atop
        |-atopacctd
        |-avahi-daemon(avahi)---avahi-daemon
        |-blkmapd
        |-bluetoothd
        |-cron
        |-cups-browsed---2*[{cups-browsed}]
        |-cupsd
        |-dbus-daemon(messagebus)
        |-dhcpd
        |-exim4(Debian-exim)
        |-hostapd
        |-nfsdcld
        |-openvpn
        |-polkitd(polkitd)---2*[{polkitd}]
        |-rpc.idmapd
        |-rpc.mountd
        |-rpc.statd(statd)
        |-rpcbind(_rpc)
        |-rtkit-daemon(rtkit)---2*[{rtkit-daemon}]
        |-sddm-+-Xorg---10*[{Xorg}]
        |      |-sddm-helper---sddm-greeter(sddm)---11*[{sddm-greeter}]
        |      `-{sddm}
        |-smartd
        |-sshd-+-sshd---sshd(bisztynek)
        |      `-sshd---sshd(kamil)---bash---tmux: client
        |-systemd(sddm)-+-(sd-pam)
        |               |-dbus-daemon
        |               `-pulseaudio-+-gsettings-helpe---3*[{gsettings-helpe}]
        |                            `-2*[{pulseaudio}]
        |-systemd(kamil)-+-(sd-pam)
        |                |-dbus-daemon
        |                `-pulseaudio-+-gsettings-helpe---3*[{gsettings-helpe}]
        |                             `-{pulseaudio}
        |-systemd(bisztynek)-+-(sd-pam)
        |                    |-dbus-daemon
        |                    `-pulseaudio-+-gsettings-helpe---3*[{gsettings-helpe}]
        |                                 `-{pulseaudio}
        |-systemd-journal
        |-systemd-logind
        |-systemd-timesyn(systemd-timesync)---{systemd-timesyn}
        |-systemd-udevd
        |-tmux: server(kamil)---bash---pstree
        |-transmission-da(debian-transmission)---3*[{transmission-da}]
        |-udisksd---4*[{udisksd}]
        |-upowerd---2*[{upowerd}]
        `-wpa_supplicant

    @Failing1 $ pstree -lu
systemd-+-VGAuthService
        |-agetty
        |-cron
        |-dbus-daemon(messagebus)
        |-dhclient
        |-nmbd
        |-rsyslogd---3*[{rsyslogd}]
        |-smbd-+-cleanupd
        |      |-smbd
        |      `-smbd-notifyd
        |-sshd---sshd---sshd(kamil)---bash---tmux: client
        |-systemd(kamil)---(sd-pam)
        |-systemd-journal
        |-systemd-logind
        |-systemd-timesyn(systemd-timesync)---{systemd-timesyn}
        |-systemd-udevd
        |-tmux: server(kamil)-+-2*[bash---nano]
        |                     `-bash---pstree
        `-vmtoolsd---2*[{vmtoolsd}]

    Other systems from the Failing group may run slightly different sets of tasks, they are all similarly minimalistic though.

Observation

One big difference between the Successful Debian and each Failing one is the GUI. There are Xorg, sddm and related processes on Successful. But as I said, I don't log in to the GUI at all. I don't know if it has anything do do with the problem. Maybe it's just a red herring.

Improve this question

1 Answer 1

Reset to default
2

While creating the question, I noticed polkitd running in the Successful system, but not in any Failing one. I knew the problem has much to do with polkit, so I gave it a try in one Debian of the Failing group:

sudo apt-get install polkitd

And yes, this is it, problem solved. Now I can use systemd-inhibit --what=idle as a regular user.

I think on the Successful Debian polkitd was installed because of other packages (e.g. network-manager) that depend on it.

Originally the question was not supposed to be self-answered, I genuinely needed help. An example of rubber duck debugging, I guess.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.