Cron: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 6: Zeile 6:
 
[[Bild:cron-namensherkunft.png]]
 
[[Bild:cron-namensherkunft.png]]
  
* Der cron-Daemon ist eine Jobsteuerung für wiederkehrende Aufgaben, die automatisch zu einer bestimmten Zeit aufgeführt werden sollen (cronjobs).
+
* Der cron-Daemon ist eine Jobsteuerung für wiederkehrende Aufgaben, die automatisch zu einer bestimmten Zeit ausgeführt werden sollen (cronjobs).
 
* z.B. Archivieren und Löschen von Logdateien, Erneuern von Zertifikaten, [https://www.duckdns.org/install.jsp DynDNS] oder andere Programme zur Instandhaltung des Systems
 
* z.B. Archivieren und Löschen von Logdateien, Erneuern von Zertifikaten, [https://www.duckdns.org/install.jsp DynDNS] oder andere Programme zur Instandhaltung des Systems
 
* Der Cron-Daemon überwacht dazu verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen (crontabs).
 
* Der Cron-Daemon überwacht dazu verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen (crontabs).
Zeile 24: Zeile 24:
  
 
* Befindet sich unter ''/etc/crontab''
 
* Befindet sich unter ''/etc/crontab''
* Das Format unterscheidet sich etwas von den Benutzercrontabs
+
* Das Format unterscheidet sich etwas von den Benutzercrontabs: es gibt eine zusätzliche Spalte für den Benutzer, unter dem der Job laufen soll
  
 
== /etc/cron.d/ ==
 
== /etc/cron.d/ ==
  
* Hier können sich Dateien im selben Format wie in ''/etc/crontab'' befinden
+
* Hier liegen Dateien im selben Format wie ''/etc/crontab'' – also mit Zeitfeldern und Benutzerspalte
* nützlich für Snippets
+
* Nützlich für Snippets, vor allem für Pakete, die eigene Jobs mitbringen
* Alternativ auch in ''cron.daily'', ''cron.hourly'', ''cron.monthly'' oder ''cron.weekly''
+
 
 +
== cron.hourly, cron.daily, cron.weekly, cron.monthly ==
 +
 
 +
* '''Anderes Prinzip:''' Hier liegen keine Crontab-Zeilen, sondern '''ausführbare Skripte ohne jede Zeitangabe'''
 +
* Wann sie laufen, steht in ''/etc/crontab'' bzw. wird von ''anacron'' bestimmt
 +
* Die Datei muss ausführbar sein und darf keinen Punkt im Namen haben – ''backup.sh'' wird ignoriert, ''backup'' läuft
  
 
= Aufbau einer Crontab-Datei =
 
= Aufbau einer Crontab-Datei =
Zeile 42: Zeile 47:
 
  │ └────────── Stunde (0-23)
 
  │ └────────── Stunde (0-23)
 
  └──────────── Minute (0-59)
 
  └──────────── Minute (0-59)
z.B. wöchtenliches Backup der Heimatverzeichnisse aller Benutzer um 3 Uhr morgens:
+
 
 +
z.B. wöchentliches Backup der Heimatverzeichnisse aller Benutzer um 3 Uhr morgens:
  
 
  0 3 * * 1 tar -zcf /var/backups/home.tgz /home/
 
  0 3 * * 1 tar -zcf /var/backups/home.tgz /home/
 +
 +
;Achtung beim Prozentzeichen
 +
* In der Crontab bedeutet ein unmaskiertes <code>%</code> einen Zeilenumbruch – alles dahinter wird zur Standardeingabe des Befehls
 +
* Datumsformate müssen deshalb maskiert werden:
 +
0 3 * * 1 tar -zcf /var/backups/home-$(date +\%F).tgz /home/
 +
 
=Beispiele=
 
=Beispiele=
 
;<nowiki>*</nowiki>/2 - Dieser Eintrag führt die Aufgabe alle 2 Minuten aus.  
 
;<nowiki>*</nowiki>/2 - Dieser Eintrag führt die Aufgabe alle 2 Minuten aus.  
Zeile 52: Zeile 64:
 
;5-9 - Dieser Eintrag führt die Aufgabe von Minute 5 bis Minute 9 in jeder Stunde aus.  
 
;5-9 - Dieser Eintrag führt die Aufgabe von Minute 5 bis Minute 9 in jeder Stunde aus.  
 
  5-9 * * * * /pfad/zum/skript.sh
 
  5-9 * * * * /pfad/zum/skript.sh
 +
 +
= Die Umgebung im Cron =
 +
 +
* Cron startet den Job '''nicht''' in Ihrer Login-Umgebung: <code>PATH</code> ist auf <code>/usr/bin:/bin</code> beschränkt, <code>.bashrc</code> und <code>.profile</code> werden nicht gelesen
 +
* Das ist der häufigste Grund für „im Terminal geht es, im Cron nicht"
 +
* Deshalb im Job absolute Pfade verwenden oder <code>PATH</code> oben in der Crontab setzen:
 +
PATH=/usr/local/bin:/usr/bin:/bin
 +
* Zum Nachsehen, was der Job tatsächlich vorfindet:
 +
* * * * * env > /tmp/cronenv.txt
 +
 +
= Lief der Job? =
 +
 +
* Cron protokolliert jeden Start – unabhängig davon, ob der Befehl selbst funktioniert hat
 +
;Debian
 +
*journalctl -fu cron
 +
;Rocky
 +
*journalctl -u crond -f
 +
* Ausgaben des Befehls gehen per Mail an den Benutzer. Ist kein Mailsystem eingerichtet, sind sie weg – deshalb im Job umleiten:
 +
0 3 * * 1 /pfad/zum/skript.sh >> /var/log/mein-job.log 2>&1
  
 
= Verwaltung von Crontab =
 
= Verwaltung von Crontab =
Zeile 75: Zeile 106:
 
* '''crontab ''/Pfad/zur/Datei'''''
 
* '''crontab ''/Pfad/zur/Datei'''''
  
= Cron vs. Daemon (Hintergrundprozess) =
+
= Alternative Systemd =
 +
 
 +
* Systemd-Service-Dateien haben auch eine [[Systemd Service timers|Timer]]-Funktion
 +
* Vorteile gegenüber Cron:
 +
** Sekundenauflösung statt Minute
 +
** <code>Persistent=true</code> holt verpasste Läufe nach, wenn die Maschine zur fälligen Zeit aus war
 +
** Die Ausgabe landet im Journal und ist mit <code>journalctl -u</code> abrufbar, statt per Mail verloren zu gehen
 +
** Abhängigkeiten zu anderen Units sind möglich
  
* Ein Daemon läuft immer, d.h.:
+
= Aufgaben =
** + Updates laufen häufiger als einmal pro Minute
 
** + Es kann sich an seinen vorherigen Status erinnern, falls es notwendig ist
 
** - Verbraucht RAM selbst wenn es gerade nichts tut
 
** - Memory Leaks sind ein Problem, falls es sie gibt
 
** - Abhängig von der Implementation wird es nicht automatisch bei Fehlern neu gestartet
 
* Wenn man also eher robuste Aufgaben verteilt, empfiehlt sich Cron.
 
* Bei performance-lastigen Aufgaben eher ein Daemon.
 
  
;Man muss aber je nach Situation selbst entscheiden, was mehr Sinn macht.
+
== Aufgaben 1 ==
  
= Alternative Systemd =
+
* Erstellen Sie einen Cron-Job, der jede halbe Stunde den Inhalt von /tmp nach /var/log/tmp.log schreibt.
 +
<!-- Lösung:
 +
crontab -e
 +
*/30 * * * * ls /tmp > /var/log/tmp.log
 +
-->
 +
 
 +
* Erstellen Sie einen Cron-Job, der von Montag bis Freitag um 11 Uhr die Dateien aus /bin nach /root sichert.
 +
<!-- Lösung:
 +
0 11 * * 1-5 cp -a /bin /root
 +
-->
 +
 
 +
* Erstellen Sie einen Cron-Job, der jede Minute den aktuellen Speicherverbrauch in eine Logdatei schreibt.
 +
<!-- Lösung:
 +
* * * * * free -m >> ~/speicher.log
 +
-->
 +
 
 +
* Erstellen Sie einen Cron-Job, der jeden Tag um 12 Uhr mittags eine Datei mit dem Datum im Namen anlegt. Achten Sie auf das Prozentzeichen.
 +
<!-- Lösung:
 +
0 12 * * * touch ~/datei_$(date +\%Y\%m\%d).txt
 +
-->
 +
 
 +
* Erstellen Sie einen Cron-Job, der jeden Montag um 3 Uhr morgens ein Backup Ihres Home-Verzeichnisses erstellt.
 +
<!-- Lösung:
 +
0 3 * * 1 tar -zcf ~/backup_$(date +\%Y\%m\%d).tgz ~/
 +
-->
 +
 
 +
* Prüfen Sie im Log, ob die Jobs gestartet wurden.
 +
<!-- Lösung: grep CRON /var/log/syslog bzw. journalctl -u crond -->
 +
 
 +
* Lassen Sie sich Ihre Crontab anzeigen und löschen Sie anschließend alle Jobs.
 +
<!-- Lösung: crontab -l ; crontab -r -->
 +
 
 +
== Aufgaben 2: Backup-Server mit Cron ==
 +
 
 +
* Installieren Sie nfs-common (Debian) bzw. nfs-utils (Rocky).
 +
<!-- Lösung: apt install -y nfs-common -->
 +
 
 +
* Erstellen Sie das Verzeichnis /mnt/backup.
 +
<!-- Lösung: mkdir /mnt/backup -->
 +
 
 +
* Tragen Sie die Freigabe in die /etc/fstab ein:
 +
192.168.6.200:/mnt/data /mnt/backup nfs defaults 0 0
 +
 
 +
* Laden Sie die Konfiguration neu, hängen Sie ein und kontrollieren Sie die Anbindung.
 +
<!-- Lösung: systemctl daemon-reload ; mount -a ; findmnt /mnt/backup -->
  
* Systemd-Service Dateien haben auch eine [[Systemd Service timers|Timer]]-Funktion, wenn man sie einstellen will.
+
* Erstellen Sie in /mnt/backup ein Verzeichnis mit Ihrem Hostnamen.
* Kann manchmal präziser sein, da Systemd die Zeit ab dem Boot zählt.
+
<!-- Lösung: mkdir /mnt/backup/$(hostname) -->
  
= Aufgaben =
+
* Erstellen Sie einen Cron-Job, der stündlich Ihr /etc in dieses Verzeichnis sichert. Die Sicherung soll einen Namen in der Art '''2024-07-17-15-30-etc''' erhalten.
 +
<!-- Lösung:
 +
0 * * * * tar -zcf /mnt/backup/$(hostname)/$(date +\%Y-\%m-\%d-\%H-\%M)-etc.tgz /etc
 +
-->
  
* [[Aufgaben cron]]
+
* Warum muss hier besonders auf das Prozentzeichen geachtet werden?
 +
<!-- Lösung: der Dateiname besteht fast nur aus Datumsformaten. Unmaskiert bricht cron die Zeile beim ersten % ab, der Rest wird zur Standardeingabe von tar. -->

Aktuelle Version vom 27. August 2026, 12:43 Uhr

Chronos Tabula

  • Der Name leitet sich vom griechischen Wort für Zeit ab
  • Der Entwickler hat sich jedoch verschrieben

Cron-namensherkunft.png

  • Der cron-Daemon ist eine Jobsteuerung für wiederkehrende Aufgaben, die automatisch zu einer bestimmten Zeit ausgeführt werden sollen (cronjobs).
  • z.B. Archivieren und Löschen von Logdateien, Erneuern von Zertifikaten, DynDNS oder andere Programme zur Instandhaltung des Systems
  • Der Cron-Daemon überwacht dazu verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen (crontabs).
  • Beim Start des Daemons wird die Tabelle in den Arbeitsspeicher geladen
  • Es wird minütlich nach auszuführenden Jobs und Änderungen im crontab geprüft

Crontabs

  • Um Syntaxfehler zu vermeiden, werden die Tabellen nicht nur mit dem Texteditor bearbeitet, sondern über den Befehl: crontab

User-Crontab

  • Jeder Benutzer des Systems kann eine eigene Crontab erstellen und bearbeiten
  • Die Jobs, die darin aufgeführt sind, werden von Cron unter der jeweiligen Benutzerkennung ausgeführt

Systemweiter Crontab

  • Befindet sich unter /etc/crontab
  • Das Format unterscheidet sich etwas von den Benutzercrontabs: es gibt eine zusätzliche Spalte für den Benutzer, unter dem der Job laufen soll

/etc/cron.d/

  • Hier liegen Dateien im selben Format wie /etc/crontab – also mit Zeitfeldern und Benutzerspalte
  • Nützlich für Snippets, vor allem für Pakete, die eigene Jobs mitbringen

cron.hourly, cron.daily, cron.weekly, cron.monthly

  • Anderes Prinzip: Hier liegen keine Crontab-Zeilen, sondern ausführbare Skripte ohne jede Zeitangabe
  • Wann sie laufen, steht in /etc/crontab bzw. wird von anacron bestimmt
  • Die Datei muss ausführbar sein und darf keinen Punkt im Namen haben – backup.sh wird ignoriert, backup läuft

Aufbau einer Crontab-Datei

* * * * * auszuführender Befehl
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ └──── Wochentag (0-7 oder Sun, Mon, Tue,etc) (Sonntag =0 oder =7)
│ │ │ └────── Monat (1-12 oder Jan, Feb, etc)
│ │ └──────── Tag (1-31)
│ └────────── Stunde (0-23)
└──────────── Minute (0-59)

z.B. wöchentliches Backup der Heimatverzeichnisse aller Benutzer um 3 Uhr morgens:

0 3 * * 1 tar -zcf /var/backups/home.tgz /home/
Achtung beim Prozentzeichen
  • In der Crontab bedeutet ein unmaskiertes % einen Zeilenumbruch – alles dahinter wird zur Standardeingabe des Befehls
  • Datumsformate müssen deshalb maskiert werden:
0 3 * * 1 tar -zcf /var/backups/home-$(date +\%F).tgz /home/

Beispiele

*/2 - Dieser Eintrag führt die Aufgabe alle 2 Minuten aus.
*/2 * * * * /pfad/zum/skript.sh
1,3,5,9 - Dieser Eintrag führt die Aufgabe zu bestimmten Minuten aus, nämlich 1, 3, 5 und 9.
1,3,5,9 * * * * /pfad/zum/skript.sh
5-9 - Dieser Eintrag führt die Aufgabe von Minute 5 bis Minute 9 in jeder Stunde aus.
5-9 * * * * /pfad/zum/skript.sh

Die Umgebung im Cron

  • Cron startet den Job nicht in Ihrer Login-Umgebung: PATH ist auf /usr/bin:/bin beschränkt, .bashrc und .profile werden nicht gelesen
  • Das ist der häufigste Grund für „im Terminal geht es, im Cron nicht"
  • Deshalb im Job absolute Pfade verwenden oder PATH oben in der Crontab setzen:
PATH=/usr/local/bin:/usr/bin:/bin
  • Zum Nachsehen, was der Job tatsächlich vorfindet:
* * * * * env > /tmp/cronenv.txt

Lief der Job?

  • Cron protokolliert jeden Start – unabhängig davon, ob der Befehl selbst funktioniert hat
Debian
  • journalctl -fu cron
Rocky
  • journalctl -u crond -f
  • Ausgaben des Befehls gehen per Mail an den Benutzer. Ist kein Mailsystem eingerichtet, sind sie weg – deshalb im Job umleiten:
0 3 * * 1 /pfad/zum/skript.sh >> /var/log/mein-job.log 2>&1

Verwaltung von Crontab

Eigene Crontab anzeigen

  • crontab -l

Crontab eines anderen Benutzers anzeigen

  • crontab -lu Benutzer

Crontab bearbeiten

  • crontab -e

Crontab löschen

  • crontab -r

Crontab aus einer Datei lesen

  • crontab /Pfad/zur/Datei

Alternative Systemd

  • Systemd-Service-Dateien haben auch eine Timer-Funktion
  • Vorteile gegenüber Cron:
    • Sekundenauflösung statt Minute
    • Persistent=true holt verpasste Läufe nach, wenn die Maschine zur fälligen Zeit aus war
    • Die Ausgabe landet im Journal und ist mit journalctl -u abrufbar, statt per Mail verloren zu gehen
    • Abhängigkeiten zu anderen Units sind möglich

Aufgaben

Aufgaben 1

  • Erstellen Sie einen Cron-Job, der jede halbe Stunde den Inhalt von /tmp nach /var/log/tmp.log schreibt.
  • Erstellen Sie einen Cron-Job, der von Montag bis Freitag um 11 Uhr die Dateien aus /bin nach /root sichert.
  • Erstellen Sie einen Cron-Job, der jede Minute den aktuellen Speicherverbrauch in eine Logdatei schreibt.
  • Erstellen Sie einen Cron-Job, der jeden Tag um 12 Uhr mittags eine Datei mit dem Datum im Namen anlegt. Achten Sie auf das Prozentzeichen.
  • Erstellen Sie einen Cron-Job, der jeden Montag um 3 Uhr morgens ein Backup Ihres Home-Verzeichnisses erstellt.
  • Prüfen Sie im Log, ob die Jobs gestartet wurden.
  • Lassen Sie sich Ihre Crontab anzeigen und löschen Sie anschließend alle Jobs.

Aufgaben 2: Backup-Server mit Cron

  • Installieren Sie nfs-common (Debian) bzw. nfs-utils (Rocky).
  • Erstellen Sie das Verzeichnis /mnt/backup.
  • Tragen Sie die Freigabe in die /etc/fstab ein:
192.168.6.200:/mnt/data /mnt/backup nfs defaults 0 0
  • Laden Sie die Konfiguration neu, hängen Sie ein und kontrollieren Sie die Anbindung.
  • Erstellen Sie in /mnt/backup ein Verzeichnis mit Ihrem Hostnamen.
  • Erstellen Sie einen Cron-Job, der stündlich Ihr /etc in dieses Verzeichnis sichert. Die Sicherung soll einen Namen in der Art 2024-07-17-15-30-etc erhalten.
  • Warum muss hier besonders auf das Prozentzeichen geachtet werden?