Silently Failing systemd User Timers
You have a systemd user timer that is loaded, enabled, and active, with user lingering turned on. However, it refuses to schedule its next run. Checking systemctl --user status shows Trigger: n/a, and systemctl --user list-timers shows a dash (-) under the NEXT column.
You go through the standard checklist—running daemon-reload, checking if the underlying .service is stuck, and verifying loginctl enable-linger—but nothing works.
The Root Cause
The vital clue is often found in this system warning:
User sessions running outdated binaries: hyxi @ user manager service: systemd[1174]
When your OS updates the systemd package, the main system daemon is updated, but your user-level daemon (in this case, PID 1174) keeps executing the older binary from memory. This stale state breaks the user session’s internal scheduler, causing otherwise perfectly configured timers to freeze and stop calculating future calendar events.
The Solution
You must flush out the stale user daemon so systemd can load the newly updated binary from disk. The most definitive way to resolve this is to completely terminate your user session.
(Note: This will immediately log you out and close all active SSH or graphical sessions).
Bash
loginctl terminate-user $USER
As soon as you log back in, a fresh user systemd instance will spawn using the correct binaries. Check systemctl --user list-timers, and your schedules will be fully restored.
Comments