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.
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) callsorg.freedesktop.PowerManagement.Inhibitwhen thesession 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:
Connector state is read from
/sys/class/drm/card1-DP-1/dpms, idle fromXScreenSaverQueryInfo(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:
and the connector at the same second:
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:
sudo /usr/bin/mint-refresh-cacheby 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 | SUSPENDand deliberately leaves out the idle flag;org.freedesktop.PowerManagement.Inhibithas 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:Both actions are allowed for the GUI process without any prompt:
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.