Таймер Systemd срабатывает после приостановки, несмотря на постоянный =false?

Я не могу понять, как должны вести себя системные таймеры, когда хост приостановлен:

Вот простой сервис: foo.service

      [Unit]
Description=Test timer

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

И соответствующий таймер: foo.timer

      [Unit]
Description=Run foo every day

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

Если я запущу таймер, приостановите хост с помощьюsystemctl suspendза несколько секунд до истечения таймера и через несколько минут пробуждает систему, таймер срабатывает, и TEST TIMER печатается в журнале.

Журнал отладки systemd примерно гласит:

      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

а потом

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

Однако этот таймер не является постоянным и, насколько я понимаю, не должен срабатывать. Для OnClockChange также установлено значение false. Остановка и перезапуск хоста не запускают таймер, возможно, потому, что весь таймер останавливается перед выключением.

Это на только что установленной виртуальной машине Arch.

Если это ожидаемое поведение, я считаю, что единственный способ отключить таймер — это поиграть с зависимостями Sleep.target?

Если это имеет значение, мой вариант использования следующий: я хотел бы приостанавливать работу хоста каждый день в определенное время. Однако если я вручную приостановлю хост на некоторое время до истечения таймера, таймер сработает, как только хост проснется, что не идеально…

РЕДАКТИРОВАТЬ: согласно https://github.com/systemd/systemd/issues/26166#issuecomment-1581501093 .

Это ожидаемое поведение таймера systemd:

      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.
Источник

1 ответ

Кажется, это ошибка в systemd , такого быть не должно. Информации об этом не так много, но из описания ошибки похоже, что сохранение применимо только к фактическому времени простоя, то есть когда компьютер выключен (в отличие от режима гибернации/приостановки). Я думаю, пока это не будет исправлено, вам следует использовать сценарий оболочки, который приостанавливает ваш компьютер только в том случае, если текущее время ± соответствует желаемому времени. В противном случае он должен выйти, ничего не делая. Действительно уродливо, неидеально и противоречит цели таймеров, но это то, что есть.

Вот скрипт, который это делает:

      #!/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

это военное время, когда ожидается истечение вашего таймера (в вашем случае 17:47),— это количество минут после этого времени, когда ему еще разрешено срабатывать, я думаю, 5 минут — приличный запас.

Источник
Другие вопросы по тегам