Ich bin wirklich dazu übergangen, mich komplett auf systemd-Timer statt Crontab-Einträge einzulassen, lediglich die Zeitangaben für kalendergebundene Events machen mir dauerhaft zu schaffen. Mir ist ein Rätsel, dass die allwissenden systemd-Entwickler darauf verzichtet haben, eine zusätzliche Konfigurationsmöglichkeit über die bekannten, selbsterklärenden und intuitiv verständlichen Crontab-Spezifikationen zu akzeptieren. Hier also eine Handvoll Beispiele:
| Wann | Crontab | OnCalendar |
|---|---|---|
| Täglich um Uhr | 45 13 * * * | 13:45:00 |
| Alle 5 Minuten | */5 * * * * | *:00/5:00 |
| Montags, Mittwoch, Donnerstag um Uhr | 14 9 * * 1,3,5 | Mon,Wed,Fri 09:14:00 |
| Montag bis Freitag um Uhr | 0 4 * * 1-5 | Mon..Fri 04:00:00 |
| Jeden Monatsersten um Uhr | 0 6 1 * * | *-*-1 06:00:00 |
| Alle 5 Minuten von 06:00 – 17:55 | */5 6-17 * * * | 06..17:00/5:00 |
Die Werte sind somit nicht für copy&paste geeignet.
Zum Testen mit systemd-analyze wird die jeweilige Definition mit Anführungszeichen übergeben:
systemd-analyze calendar --iterations=10 'Mon,Wed,Fri 09:14:00'
In der Timer-Unit dürfen dann keine Anführungszeichen stehen, und nein, das ergibt überhaupt keinen Sinn.
[Unit]
Description=Ein kalenderbasierter Timer
[Timer]
OnCalendar=Mon,Wed,Fri 09:14:00
[Install]
WantedBy=timers.target
Alternativ, insbesondere bei hoher Ausführungsfrequenz oder bei Überschneidungsgefahr, benutze ich, wenn ich schon in systemd unterwegs bin, heute gern monotone Timer.
[Unit]
Description=Ein monotoner Timer
[Timer]
OnStartupSec=60
OnUnitInactiveSec=900
[Install]
WantedBy=timers.target
Versuche, hybride Timer mit Elementen aus beiden Timer-Typen zu konfigurieren, haben bei mir keine Fehlermeldungen produziert, aber der OnCalendar-Teil der Konfiguration wurde ignoriert. Das genaue Verhalten scheint nicht definiert zu sein.
WantedBy sollte bei Timern im Systemkontext auf timers.target lauten, da damit die NTP-Synchronisation vorm Start des Timer sichergestellt ist. Im Userkontext (Wallpaperchanger, Zeiterfassung, dies das) steht nur default.target zur Verfügung.
Inb4, warum überhaupt auf systemd-Timer statt crontab einlassen? Ganz einfach, weil systemd-Timer absolut narrensicher zu managen sind:
- Du willst einen systemd-Timer verteilen/managen/paketieren? Kein Problem. Zwei Dateien nach /etc/systemd/system packen, systemctl daemon-reload, systemctl enable, fertig. Anders als in der Crontab musst du dir keine Meta-Syntax ausdenken, um zu identifizieren, ob der Eintrag schon da ist, und um ihn punktgenau löschen zu können.
- Du willst einen vorinstallierten Timer anpassen? Ebenfalls kein Problem. Du legst ein Drop-In daneben, in dem du deine neue Timer-Spezifikation hinterlegst, etwa /etc/systemd/system/apt-daily.timer.d/local.conf als Drop-In für /lib/systemd/system/apt-daily.timer.
Grundlagen zu Timern finden sich etwa im Arch-Wiki oder bei Ubuntu Users.
@binblog ich finde die OnCalendar Notation einfacher. Aber ich muss seit fast 20 Jahren die Cronnotatin nachschlagen 😅
@binblog @isotopp Mit systemd Timer habe ich ein Dienst erstellt, welcher Usersessions jeden Abend an einem bestimmten Zeitpunkt beendigt. Somit sind die Hopserver jede Nacht Benutzerlos.Wir haben da so einige Pappenheimer mit tmux/screen, mehr muss ich nicht sagen.Ich versuche bei uns seit einiger Zeit cron gegen systemd Timer zu ersetzen. Ich hoffe es fruchtet bald
@binblogAlle die systemctl list-timers Funktion für alle Timer über ALLE user ist schon Gold wert gegenüber cron.
@binblog> Mir ist ein Rätsel, dass die allwissenden systemd-Entwickler darauf verzichtet haben, eine zusätzliche Konfigurationsmöglichkeit über die bekannten, selbsterklärenden und intuitiv verständlichen Crontab-Spezifikationen zu akzeptieren.Ist doch satire, oder? Mit systemd timers kommt übrigens das erste mal die Möglichkeit sekundengenau oder zufällig zeitversetzt zu starten.Die wunderbare Leerzeichen config wie bei cron ist uns übrigens in tmpfiles.d erhalten geblieben
> Zum Testen mit systemd-analyze wird die jeweilige Definition mit Anführungszeichen übergeben:
> $ systemd-analyze calendar –iterations=10 ‘Mon,Wed,Fri 09:14:00’
> In der Timer-Unit dürfen dann keine Anführungszeichen stehen, und nein, das ergibt überhaupt keinen Sinn.
Wenn du die Sonderzeichen sauber escapest, dann geht das auch in der shell ohne Anführungszeichen:
$ systemd-analyze calendar –iterations=10 Mon,Wed,Fri\ 09:14:00
In dem Fall ist der Space das was es kaputt macht