On Wed, 30 Jul 2025 18:43:17 +0100 Luca Boccassi <[email protected]> wrote: > Control: tags -1 moreinfo > > On Wed, 30 Jul 2025 19:15:13 +0200 loomylabs <[email protected]> > wrote: > > Package: systemd > > Version: 252.38-1~deb12u1 > > Severity: normal > > X-Debbugs-Cc: [email protected] > > > > 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?
