Systemd Timer Units für zeitgesteuerte Aufgaben verwenden
Die Korrektheit der Unit-Dateien verifizieren
Man kann das Kommando systemd-analyze mit der Option verify verwenden, um die Korrektheit der Unit-Dateien zu prüfen. Falls Syntaxfehler vorhanden sind, wird es darauf hinweisen.
$ sudo systemd-analyze verify /etc/systemd/system/my-rsync.* [savona@centos7 bin]$
Wenn nichts ausgegeben wird, wurde die Datei erfolgreich verifiziert.
Den systemd-Timer starten
Wir sind nun bereit, den Timer zu starten. Dazu wird systemctl verwendet.
$ sudo systemctl start my-rsync.timer
Dauerhaftes Aktivieren des Systemd-Timers
Man kann den Systemd-Timer genauso aktivieren wie jeden anderen Service.
$ sudo systemctl enable my-rsync.timer
Den Job manuell starten
Falls man den Job einmal manuell ausführen will, kann man einfach den Service starten. Hier ein Beispiel:
$ ls -l /mnt/usb/ total 0 $ sudo systemctl start my-rsync.service $ ls -l /mnt/usb/ total 40 drwxr-xr-x. 5 savona savona 4096 Mar 3 18:40 Desktop drwxr-xr-x. 2 savona savona 4096 Jan 23 23:10 Documents drwxr-xr-x. 2 savona savona 4096 Jan 23 23:10 Downloads -rwxrwxr-x. 1 savona savona 104 Feb 28 21:05 hello.sh drwxr-xr-x. 2 savona savona 4096 Jan 23 23:10 Music drwxr-xr-x. 2 savona savona 4096 Jan 23 23:10 Pictures drwxr-xr-x. 2 savona savona 4096 Jan 23 23:10 Public drwxrwxr-x. 2 savona savona 4096 Feb 28 21:18 scripts drwxr-xr-x. 2 savona savona 4096 Jan 23 23:10 Templates drwxr-xr-x. 2 savona savona 4096 Jan 23 23:10 Videos
In diesem Fall haben wir das Skript ja im PATH abgelegt, so dass die manuelle Ausführung auch einfach dadurch geschehen kann, dass man das Skript unter seinem Namen aufruft.
$ my-rsync.sh
Ansehen der Systemd Timer-Logs mit Journalctl
Wie eingangs erwähnt, ist einer der Vorteile der Nutzung von Systemd-Timern, dass sie im Systemd-Journal geloggt werden. Wir können daher die entsprechenden Log-Einträge mit journalctl mit der Option -u (unit) ansehen.
$ sudo journalctl -u my-rsync -- Logs begin at Sun 2019-04-07 19:00:33 EDT, end at Sun 2019-04-07 19:05:55 EDT. -- Apr 07 19:03:39 centos7 systemd[1]: Started "A script to backup all home dirs to usb drive". Apr 07 19:03:39 centos7 my-rsync.sh[14589]: sending incremental file list Apr 07 19:03:39 centos7 my-rsync.sh[14589]: ./ Apr 07 19:03:39 centos7 my-rsync.sh[14589]: .ICEauthority Apr 07 19:03:39 centos7 my-rsync.sh[14589]: [105B blob data] Apr 07 19:03:39 centos7 my-rsync.sh[14589]: .bash_history Apr 07 19:03:39 centos7 my-rsync.sh[14589]: [105B blob data] ...
Fazit
In diesem Tutorial haben wir die Vorzüge von Systemd-Timer-Units im Vergleich zu Cron-Jobs erörtert. Es geht uns aber nicht darum, die Wichtigkeit von Cron herunterzuspielen. Beide Werkzeuge haben ihre Vorzüge, und manchmal ist weniger mehr. Wenn man einfach einen Job jeden Abend um 18 Uhr starten will, wäre Cron für mich die bessere Wahl. Wenn man jedoch einen Job 30 Sekunden nach dem Booten, aber nur wenn das Netzwerk verfügbar ist, starten will, dann ist eine Systemd-Unit wahrscheinlich vorzuziehen.
Hinweis
Dieser Artikel ist im Original auf pustorius.net erschienen. Übersetzung und Veröffentlichung mit freundlicher Genehmigung.
