Skip to content

Scheduled refresh wakes the monitor on Xfce — the power-management inhibitor disables DPMS #1093

Description

@lbellows

Mint 22.3 Xfce, mintupdate 7.1.4, xfce4-power-manager 4.18.4, systemd. Same code on current master.

On an idle machine with nobody at it, every scheduled refresh powers the monitor back on. With the
default 2-hour schedule (two staggered series on this box) the panel was lit roughly 15 minutes of
every hour, around the clock.

The trigger is the inhibitor, not the apt or flatpak work. inhibit_pm() in 7.1.4
(util.Inhibitor.inhibit() on master) calls org.freedesktop.PowerManagement.Inhibit when the
session is Xfce, and xfce4-power-manager implements that by disabling DPMS — which powers a
currently-blanked panel back on.

That call on its own, panel off, no input for 654 s:

09:12:01 panel Off, idle=654s -- calling Inhibit('mintupdate', 'Checking for updates')
09:12:02 *** PANEL ON at +0.2s after Inhibit, X-idle=654s (no input) ***
09:12:02 HasInhibit=True
09:12:02 xset q says: Disabled

Connector state is read from /sys/class/drm/card1-DP-1/dpms, idle from XScreenSaverQueryInfo
(unchanged across the wake, so nothing touched the keyboard or mouse).

The matching pair from a real refresh on the same machine — mintupdate's own log:

/tmp/mintUpdate/00ev80nh
2026.09.15@08:57 ++ Changes to the package cache detected; triggering refresh
2026.09.15@08:57 ++ Inhibited power management
2026.09.15@08:57 ++ Checking for updates
2026.09.15@08:57 ++ Refresh finished
2026.09.15@08:57 ++ Resumed power management

and the connector at the same second:

2026-09-15T08:52:16 On/enabled -> Off/disabled  idle=600s
2026-09-15T08:57:06 Off/disabled -> On/enabled  idle=890s   <-- no input for 890 s

Everything else in the refresh was ruled out by running each step on its own with the panel off and
watching the connector for 40 s:

control-sleep          NO WAKE (held Off 40s)
worker-refresh         NO WAKE (held Off 40s)     flatpak-update-worker.py --refresh
control-sleep-2        NO WAKE (held Off 40s)
gtk-init               NO WAKE (held Off 40s)
mintcommon-import      NO WAKE (held Off 40s)
fp-list-installed      NO WAKE (held Off 40s)
fp-cleanup-prune       NO WAKE (held Off 40s)
installer-init-sync    NO WAKE (held Off 40s)
fp-update-appstream    NO WAKE (held Off 40s)

sudo /usr/bin/mint-refresh-cache by hand does not reproduce it either.

The inhibitor is released correctly at the end of the refresh and DPMS is re-enabled, but the idle
countdown restarts from zero, so each refresh costs a full DPMS timeout (900 s here) of lit panel.

The non-Xfce path already asks for LOGOUT | SUSPEND and deliberately leaves out the idle flag;
org.freedesktop.PowerManagement.Inhibit has no flags and always includes idle.

A logind block inhibitor gives the same protection with no display side effects. Measured in the
graphical session (session-c1.scope), panel off:

09:15:59 panel Off, idle=892s -- taking logind sleep:shutdown block inhibitor
09:15:59 got inhibitor fd=9 in 4ms
09:16:24 NO WAKE: connector held Off for 25s with the inhibitor active, idle=917s
09:16:24 xset q DPMS: Enabled
mintupdate  1000 lucy 33974 python3  shutdown:sleep  block
09:16:25 released; connector=Off

Both actions are allowed for the GUI process without any prompt:

$ pkcheck --process 1897 --action-id org.freedesktop.login1.inhibit-block-sleep    ; echo $?
0
$ pkcheck --process 1897 --action-id org.freedesktop.login1.inhibit-block-shutdown ; echo $?
0

As a bonus the fd is dropped automatically if mintupdate exits unexpectedly, so it cannot leave the
session inhibited the way a leaked cookie can (cf. #941).

Patch in the next comment / PR. Current workaround is turning the refresh schedule off entirely.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions