Gibt es eine Möglichkeit zu wissen, wann ein System-Timer als nächstes ausgeführt wird?

Ich teste einen System-Timer und versuche, dessen Standard-Timeout zu überschreiben, aber ohne Erfolg. Ich frage mich, ob es eine Möglichkeit gibt, systemd zu bitten, uns mitzuteilen, wann der Dienst als nächstes ausgeführt wird.

Normale Datei ( /lib/systemd/system/snapbackend.timer):

# Documentation available at:
# https://www.freedesktop.org/software/systemd/man/systemd.timer.html

[Unit]
Description=Run the snapbackend service once every 5 minutes.

[Timer]
# You must have an OnBootSec (or OnStartupSec) otherwise it does not auto-start
OnBootSec=5min
OnUnitActiveSec=5min
# The default accuracy is 1 minute. I'm not too sure that either way
# will affect us. I am thinking that since our computers will be
# permanently running, it probably won't be that inaccurate anyway.
# See also:
# http://stackoverflow.com/questions/39176514/is-it-correct-that-systemd-timer-accuracysec-parameter-make-the-ticks-slip
#AccuracySec=1

[Install]
WantedBy=timers.target

# vim: syntax=dosini

Die Überschreibungsdatei ( /etc/systemd/system/snapbackend.timer.d/override.conf):

# This file was auto-generated by snapmanager.cgi
# Feel free to do additional modifications here as
# snapmanager.cgi will be aware of them as expected.
[Timer]
OnUnitActiveSec=30min

Ich habe die folgenden Befehle ausgeführt und der Timer tickt immer noch alle 5 Minuten. Könnte es einen Fehler in systemd geben?

sudo systemctl stop snapbackend.timer
sudo systemctl daemon-reload
sudo systemctl start snapbackend.timer

Also habe ich mich auch gefragt, woher ich wissen kann, wann der Timer das nächste Mal läuft? Denn das würde mir sofort sagen, ob es in 5 min ist. oder 30 min. aber von dem systemctl status snapbackend.timersagt das nichts. Ich frage mich nur, ob es einen Befehl gibt, der mir die aktuell verwendete Verzögerung angibt.

Für Interessenten gibt es auch die Servicedatei ( /lib/systemd/system/snapbackend.service), obwohl ich mir vorstellen würde, dass dies keinen Einfluss auf die Timer-Ticks haben sollte ...

# Documentation available at:
# https://www.freedesktop.org/software/systemd/man/systemd.service.html

[Unit]
Description=Snap! Websites snapbackend CRON daemon
After=snapbase.service snapcommunicator.service snapfirewall.service snaplock.service snapdbproxy.service

[Service]
# See also the snapbackend.timer file
Type=simple
WorkingDirectory=~
ProtectHome=true
NoNewPrivileges=true
ExecStart=/usr/bin/snapbackend
ExecStop=/usr/bin/snapstop --timeout 300 $MAINPID
User=snapwebsites
Group=snapwebsites
# No auto-restart, we use the timer to start once in a while
# We also want to make systemd think that exit(1) is fine
SuccessExitStatus=1
Nice=5
LimitNPROC=1000
# For developers and administrators to get console output
#StandardOutput=tty
#StandardError=tty
#TTYPath=/dev/console
# Enter a size to get a core dump in case of a crash
#LimitCORE=10G

[Install]
WantedBy=multi-user.target

# vim: syntax=dosini

Der Status der aktuell aktiven Timer kann wie folgt angezeigt werden systemctl list-timers:

$ systemctl list-timers --all
NEXT                         LEFT     LAST                         PASSED       UNIT                         ACTIVATES
Wed 2016-12-14 08:06:15 CET  21h left Tue 2016-12-13 08:06:15 CET  2h 18min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

1 timers listed.

Aus @phg Kommentar und Antwort habe ich eine Seite mit der Antwort gefunden. Die Timer sind kumulativ und müssen zuerst zurückgesetzt werden, da sonst der vorherige Eintrag erhalten bleibt. Dies ist nützlich für Kalender, funktioniert jedoch bei allen Timern gleich.

Es funktioniert wie erwartet, wenn ein Eintrag den Timer zurücksetzt, bevor er auf einen neuen Wert geändert wird:

# This file was auto-generated by snapmanager.cgi
# Feel free to do additional modifications here as
# snapmanager.cgi will be aware of them as expected.
[Timer]
OnUnitActiveSec=
OnUnitActiveSec=30min

Nein, es scheint keine Möglichkeit zu geben, genau zu sehen, wann ein Timer wann das nächste Mal läuft. systemdbietet systemctl list-timersund systemctl status something.timer, aber diese zeigen nicht die Auswirkungen AccuracySec=und möglicherweise andere Richtlinien, die die Zeit verschieben.

Wenn Sie AccuracySec=1hauf zwei Servern festlegen , melden beide, dass derselbe Timer auf beiden Servern genau zur gleichen Zeit ausgelöst wird, aber tatsächlich können sie bis zu einer Stunde auseinander starten! Wenn Sie wissen möchten, ob zwei zufällige Timer kollidieren, gibt es anscheinend keine Möglichkeit, die endgültig berechnete Laufzeit zu überprüfen, um dies herauszufinden.

Es ist ein Systemproblem offen , um die Ausgabe von Listen-Timern genauer / weniger verwirrend zu gestalten.