Systemd timer triggered after suspend despite persistent=false?

JudgeGregg

11/3/23, 5:30 PM

I cannot understand how systemd timers are supposed to behave when the host is suspended:

Here is a simple service: foo.service

[Unit]
Description=Test timer

[Service]
Type=simple
ExecStart=echo "TEST TIMER"

And the corresponding timer: foo.timer

[Unit]
Description=Run foo every day

[Timer]
OnCalendar=Mon..Sun 17:47:00

If I start the timer, suspend the host with systemctl suspend a few seconds before the timer elapses, and wake the system up a few minutes later, the timer is triggered, and TEST TIMER is printed in journald.

The systemd debug log roughly says:

Nov 03 17:53:27 footest kernel: PM: suspend exit
Nov 03 17:53:27 footest kernel: random: crng reseeded on system resumption
Nov 03 17:53:27 footest kernel: Restarting tasks ... done.
Nov 03 17:53:27 footest systemd[1]: foo.timer: Timer elapsed.
Nov 03 17:53:27 footest kernel: OOM killer enabled.
Nov 03 17:53:27 footest kernel: ata1.00: configured for UDMA/133
Nov 03 17:53:27 footest kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Nov 03 17:53:27 footest kernel: sd 0:0:0:0: [sda] Starting disk

and then

Nov 03 17:53:27 footest echo[434]: TEST TIMER

However that timer is not persistent, and should not be triggered as far as I understand. OnClockChange is also set to false. Halting and restarting the host does not trigger the timer, probably because the whole timer is stopped before shutting down.

This is on a freshly installed Arch VM.

If this is the expected behavior, I take it the only way to disable the timer is to play with the sleep.target dependencies ?

My use case is the following if it matters: I'd like to suspend the host every day at a given time. However if I manually suspend the host some time before the timer elapses, the timer will trigger as soon as the host wakes up, which is not ideal…

EDIT: as per https://github.com/systemd/systemd/issues/26166#issuecomment-1581501093

This is the expected behaviour for a systemd timer:

Generally, system suspend/hibernate across the system is mostly treated as a large scheduling latency, and all programs will "catch up" on what they were missing when coming back from suspend. And so does systemd.

166

1 + 0

systemd

systemd-timers

Score:0

Server

rkfg

5/4/24, 2:48 PM

It seems to be a bug in systemd, it certainly shouldn't happen. There's not much information about it but from the bug description it looks like persistence only applies to the actual downtime, i.e. when the machine is turned off (as opposed to hibernation/suspend). I guess until it's fixed you should use a shell script that only suspends your PC if the current time ±matches your desired time. Otherwise it should exit without doing anything. Really ugly, non-ideal and defeats the purpose of timers but it is what it is.

Here's the script that does that:

#!/bin/sh
TIME=1747
DELTA=5
MAXTIME=$((TIME + DELTA))
NOW=$(date +%H%M)
if [ $NOW -ge $TIME -a $NOW -le $MAXTIME ]
then
  /bin/systemctl suspend
fi

TIME is the military time when your timer is expected to elapse (17:47 in your case), DELTA is the number of minutes after that time when it's still allowed to trigger, I think 5 minutes are a decent margin.

+ 3

JudgeGregg

5/6/24, 12:17 PM

Thank you for your answer and the link! At least I know I'm not the only one puzzled by this behavior… I will monitor the bug report and refer to it in case the bug is fixed or acknowledged.

rkfg

5/7/24, 11:19 PM

It might help it if you also comment on GitHub for visibility (describing your use case so it's not just a +1), I hope the developers pay more attention to the bugs that are actively discussed and concern multiple people.

JudgeGregg

6/15/24, 12:57 PM

Since this is the expected behavior for a timer, your workaround will be useful. Thank you!

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Systemd timer triggered after suspend despite persistent=false?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.