Acesso negado para `systemd-inhibit --what=idle`

Problema

No Debian 12 eu uso IdleAction=poweroffe IdleActionSec=…no logind.conf. Isso funciona conforme o esperado: a máquina desliga-se automaticamente quando fica ociosa por tempo suficiente.

Quero poder usar systemd-inhibit --what=idlecomo usuário normal. Encontrei afirmações de que deveria ser possível ( exemplo ). Na verdade, em um dos meus sistemas Debian 12 isso é possível, vamos chamar isso de Debian Successful ; mas existem outros sistemas Debian 12 onde eu recebo Access denied, vamos chamá-los de Failing . A máquina onde eu realmente preciso dessa funcionalidade está no grupo Failing .

Não é uma peculiaridade temporária (por causa da "necessidade de reiniciar" ou algo assim). Acabei de reiniciar a máquina Successful e uma Failing , o comportamento persiste.

Por que a diferença? O que posso fazer para que um sistema com falha se comporte como um sistema com sucesso ?

Não estou realmente interessado em soluções alternativas sudoou em algum wrapper personalizado. Eu gostaria systemd-inhibit --what=idlede "apenas trabalhar", como acontece no sistema Successful . Eu gostaria de ajustar seu comportamento tanto quanto possível "de acordo com o livro systemd/polkit".

Comportamento atual

É assim que funciona no sistema Successful . É isso que eu quero:

$ 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
$

É assim que falha nos sistemas com falha :

$ 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é apenas um exemplo. Em última análise, quero invocar algum comando de longa duração para o qual a inibição faça todo o sentido.

Detalhes

• Bem-sucedido e fracassado são o Debian 12.

• O kernel em Successful e em cada Failing é 6.1.0-17-amd64.

• A saída de 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)
  

• Em cada sistema /usr/bin/systemd-inhibitdá o mesmo md5sum, concluo que os arquivos são idênticos entre Successful e Failing ; eles não foram adulterados. ls -l /usr/bin/systemd-inhibitimpressões:

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

• Em cada sistema /usr/share/dbus-1/system.d/org.freedesktop.login1.confdá o mesmo md5sum, concluo que os arquivos são idênticos entre Successful e Failing ; eles não foram adulterados. As partes relevantes (?):

  <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>
  

• Em cada sistema /usr/share/polkit-1/actions/org.freedesktop.login1.policydá o mesmo md5sum, concluo que os arquivos são idênticos entre Successful e Failing ; eles não foram adulterados. As partes relevantes (?):

  <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>
  

  Eu acho que isso <allow_any>yes</allow_any>é responsável pela alegada capacidade de um usuário comum usar arquivos systemd-inhibit --what=idle. Ainda em Sistemas com falha parece ser ignorado.

• O Debian de sucesso usa seu hardware diretamente. Um Debian com falha está instalado no HP ProLiant DL380 G5; outros Debians com falha são máquinas virtuais no VMware ESXi 7.

• Eu uso sshpara me conectar ao sistema de sucesso e a cada um que falha . O sistema Successful fornece uma GUI, mas é "apenas por precaução"; atualmente sddmsó fica lá e eu não faço login dessa maneira.

• A saída de 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}]
  

  Outros sistemas do grupo Failing podem executar conjuntos de tarefas ligeiramente diferentes, embora sejam todos igualmente minimalistas.

Observação

Uma grande diferença entre o Debian bem-sucedido e cada um com falha é a GUI. Existem Xorge sddmprocessos relacionados em Success . Mas, como eu disse, não faço login na GUI. Não sei se tem alguma coisa a ver com o problema. Talvez seja apenas uma pista falsa.