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.