fog-agent unable to reboot a Linux computer due to active block inhibitor #30

Activity

1. mastacontrola

   transferred this issue fromFOGProject/fogprojecton Oct 14, 2026
2. mastacontrola

   closed this as completedin #31on Oct 14, 2026
3. mastacontrola commented on Oct 14, 2026

   

   mastacontrola

   on Oct 14, 2026

   Member

   More actions

   Thanks for the report. I moved it here from the fogproject repo, since the problem is in the agent.

   Cause: logind enforces systemd block inhibitor locks. The agent reboots through logind (shutdown +N or systemctl reboot), so logind refused it. The agent then retried on every poll and never rebooted. Root also cannot skip the lock with systemctl -i, because logind then asks polkit for an interactive answer.

   Fix: v0.1.16 (#31). When logind refuses, the agent now starts reboot.target directly through systemd. This is the same orderly reboot logind runs when it allows one. If a reboot has a warning delay, the agent creates fog-agent-reboot.timer for the countdown and sends the warning with wall. To cancel it, run systemctl stop fog-agent-reboot.timer. Windows already worked this way with shutdown /f.

   To get it: an agent on the "latest" update ring updates itself to v0.1.16. You can also install it from the v0.1.16 release.

   Can you tell us which program held the lock? Run systemd-inhibit --list while the reboot is blocked and paste the output. A package manager in the middle of a transaction would be cut off by the new behavior, and we want to know if that is the case you hit.
4. Sempyos commented on Oct 14, 2026

   

   Sempyos

   on Oct 14, 2026

   Author

   More actions

   It was just the gnome session

   ModemManager   0    root 1138 ModemManager    sleep                                                    ModemManager needs to reset devices                         delay
   NetworkManager 0    root 1233 NetworkManager  sleep                                                    NetworkManager needs to turn off networks                   delay
   UPower         0    root 1050 upowerd         sleep                                                    Pause device polling                                        delay
   GNOME Shell    1000 user 3340 gnome-shell     sleep                                                    GNOME needs to lock the screen                              delay
   GNOME Shell    1000 user 3340 gnome-shell     sleep                                                    GNOME needs to save screen time data                        delay
   user           1000 user 3481 gsd-power       handle-lid-switch                                        External monitor attached or configuration changed recently block
   user           1000 user 3480 gsd-media-keys  handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                                   block
   user           1000 user 3316 gnome-session-s shutdown                                                 user session inhibited                                      block
   user           1000 user 3480 gsd-media-keys  sleep                                                    GNOME handling keypresses                                   delay
   user           1000 user 3481 gsd-power       sleep                                                    GNOME needs to lock the screen                              delay
   
5. Sempyos commented on Oct 14, 2026

   

   Sempyos

   on Oct 14, 2026

   Author

   More actions

   Tested the new version, works perfectly

   However, we are running into a new issue:
   Our entirely stock Fedora 44 Workstation is not updating the client. All of our Windows 11 images were able to. There was no logs on the machine itself from journalctl or systemctl and history items > agent activity showed nothing about updating. I'm unsure if this is a known issue, so just saying here for now.

   Also if there is a more preferred communication channel for this, please let me know
6. Sempyos commented on Oct 14, 2026

   

   Sempyos

   on Oct 14, 2026

   Author

   More actions

   Nevermind that update issue, seems something caused the agent to just lock up, rebooting twice fixed it