Dear Maintainer,

I have a server configured to automatically suspend using "systemctl suspend" after X minutes of inactivity on specific monitored ports. When traffic is detected on those ports, the gateway wakes the server via Wake-on-LAN.

I have a systemd timer set to reboot the server sometime between 4 and 5 a.m.

The timer looks like this:

[Unit]
Description=Daily reboot

[Timer]
OnCalendar=*-*-* 04:00:00
RandomizedDelaySec=3600
WakeSystem=true
Unit=reboot.target

[Install]
WantedBy=timers.target

Each time the server wakes from suspend, the elapsed time is recalculated and shifts progressively further into the future, significantly surpassing the 4 to 5 o'clock window.

I attempted to fix this by enabling "FixedRandomDelay=true", but it didn't affect the behavior.

These logs show the most extreme instance I've seen to date, every time "Time change, recalculating next elapse." is logged, systemd wakes from suspend and the elapse time has slipped all the way to 10 a.m., which is 5 hours behind schedule.

journalctl logs (LogLevel=debug + FixedRandomDelay=true):
-------------------------------------------------------------------------------------------------------------------------

I suspect the issue lies with "RandomizedDelaySec", as I have not seen this drift occur without it.

Thank you for reviewing this matter.

Control: tags -1 moreinfo
suspend" after X minutes of inactivity on specific monitored ports.
When traffic is detected on those ports, the gateway wakes the server
via Wake-on-LAN.
and 5 a.m.
recalculated and shifts progressively further into the future,
significantly surpassing the 4 to 5 o'clock window.

Can you reproduce on testing or unstable?

On Wed, 30 Jul 2025 18:43:17 +0100 Luca Boccassi <bluca@debian.org> wrote:
 > Control: tags -1 moreinfo
 >
 > On Wed, 30 Jul 2025 19:15:13 +0200 loomylabs <universal.wombat@web.de>
 > wrote:
 > > Package: systemd
 > > Version: 252.38-1~deb12u1
 > > Severity: normal
 > > X-Debbugs-Cc: universal.wombat@web.de
 > >
 > > Dear Maintainer,
 > >
 > > I have a server configured to automatically suspend using "systemctl
 > suspend" after X minutes of inactivity on specific monitored ports.
 > When traffic is detected on those ports, the gateway wakes the server
 > via Wake-on-LAN.
 > >
 > > I have a systemd timer set to reboot the server sometime between 4
 > and 5 a.m.
 > >
 > > The timer looks like this:
 > >
 > > [Unit]
 > > Description=Daily reboot
 > >
 > > [Timer]
 > > OnCalendar=*-*-* 04:00:00
 > > RandomizedDelaySec=3600
 > > WakeSystem=true
 > > Unit=reboot.target
 > >
 > > [Install]
 > > WantedBy=timers.target
 > >
 > > Each time the server wakes from suspend, the elapsed time is
 > recalculated and shifts progressively further into the future,
 > significantly surpassing the 4 to 5 o'clock window.
 >
 > Can you reproduce on testing or unstable?
 >
 >


Sure, I can set up a Debian box on testing and try to reproduce the
behavior, but that will take a few days.

Aside from that, I took another look at the systemd timer documentation
and noticed this part in the "RandomizedDelaySec=" section: "The delay
is added on top of the next determined elapsing time or the service
manager's startup time, whichever is later."

Could it be that the drift is intentional? I'm not sure if a wake-up
from suspend is considered a "service manager startup," but the time
drift does seem to match the "whichever is later" condition. Looking at
the logs, I notice that the timer elapses at 04:48:58, and the wake-up
completes a few seconds later. So, systemd might interpret that as
having missed the elapse time and therefore reschedules it slightly into
the future. This cycle could then repeat a few times, resulting in
significant shifts in the elapse time.

What do you think?