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

19

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
Alexis Wilke
quelle
1
Hilft die Ausgabe von systemctl list-timers?
Phg
Ah! Auf dieser Suche fand ich diese Seite mit der Lösung: bbs.archlinux.org/viewtopic.php?id=214989 Ich werde jetzt eine Antwort schreiben.
Alexis Wilke

Antworten:

25

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.
phg
quelle
7

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
Alexis Wilke
quelle
1

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.

Mark Stosberg
quelle
Interessanter Punkt über die Timer. Die Informationen, die wir von erhalten list-timers, sind jedoch bereits ziemlich gut, um zu verstehen, ob Ihre Verwendung der Timer korrekt ist oder nicht.
Alexis Wilke
1
Nicht in meinem Fall. Ich möchte auf zwei Hosts genau dieselbe Konfiguration verwenden, verwende jedoch AccuracySec =, um sicherzustellen, dass nicht beide gleichzeitig gewartet werden. Ich möchte sehen, wann die Timer tatsächlich auf jedem Host ausgelöst werden, kann dies aber nicht.
Mark Stosberg
Ah. Ich habe ähnliche Probleme. Ich würde einen ausgewählten Master verwenden (unter Verwendung eines Abstimmungssystems) und der Master sendet eine Nachricht "do maintenance" an Computer 1, sobald Computer 1 fertig ist, meldet er seinen neuen Status an den Master, der dann Computer 2 auffordert, seine Wartung durchzuführen. usw. Einer dieser Computer wäre natürlich der Master, aber der Code, der die Wartungsschleife ausführt, sollte von der eigentlichen Wartung getrennt sein. Ein Problem zu beachten. Wenn Ihr Cluster zu wachsen , ist ziemlich viel daran erinnern , dass es Zeit braucht , und es könnte so lang sein , dass einige Computer nicht für eine lange Zeit aktualisiert werden!
Alexis Wilke