Cron und crond

Es gilt zwischen zwei Programmen zu Unterscheiden: Dem Programm „cron“ und dem Daemon „crond“. Informationen zum Aufbau der crontab-Datei findet man unter „man 5 crontab“, während „man 1 crontab“ Informationen zum Hinzufügen von Jobs enthält.

Die crontab-Datei beinhaltet nach der Installation bereits einige Einträge. Dazu gehören Informationen zur Shell die Cron verwenden soll, das HOME-Verzeichnis und eine MAILTO-Variable, die per Default in einigen Distributionen mit „root“ definiert ist (unter Debian fehlt bei mir dieser Eintrag komplett). Wenn man nur selten als Root am System angemeldet ist, sollte man hier einen anderen Benutzer oder eine gültige E-Mail Adresse eintragen.

Ausführungszeitpunkt

  • Minute(n) -> 0 – 59
  • Stunde(n) -> 0 – 23
  • Tag(e) -> 1 – 31
  • Monat(e) -> 1 – 12
  • Tag(e) der Woche -> 0 – 7 (Sonntag ist sowohl 0 als auch 7)

Wenn Werte mehrfach belegt werden sollen, werden Diese entweder mit Komma getrennt oder es wird ein (-) Strick als „von – bis“ verwendet. Ein Sternchen (* asterisk) bedeutet wie so oft „jede(r)“.

Der Syntax im Überblick

* * * * * Benutzer Befehl
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ └──── Wochentag (0-7, Sonntag ist 0 oder 7)
│ │ │ └────── Monat (1-12)
│ │ └──────── Tag (1-31)
│ └────────── Stunde (0-23)
└──────────── Minute (0-59)

Ein paar Beispiele aus der crontab von Fedora 10 sollen dies veranschaulichen:

01 * * * * root run-parts /etc/cron.hourly

Das Script „run-parts“ wird also im Benutzerkontext des Root, immer eine Minute nach der vollen Stunde, jede Stunde an jedem Tag im Monat, in jedem Monat und an beliebigen Wochentagen ausgeführt. Das Script „run-parts“ such in diesem Falle nach Skripten im Verzeichnis „/etc/cron.hourly“ und führt diese aus.

22 4 * * 0 root run-parts /etc/cron.weekly

So werden entsprechend per run-parts die Scripte unter „/etc/cron.weekly“ an jedem Sonntag (0) um 4Uhr und 22Minuten ausgeführt.

0 8,10,14,16,18 * * 1-5 root /etc/meinescripts/virenscan

Als Beispiel eines eigenen Eintrags wird hier ein Virenscan-Script gestartet. Es wird von Montag bis Freitag (1-5) jeweils um 8, 10, 14,16 und 18Uhr ausgeführt.

0/30 9-18 * * 1-5 root /etc/meinescripts/virenscan

Im letzten Beispiel bringen wir nun noch den Schrägstrich (/) mit ins Spiel. Das Virenscan-Script würde so zwischen 9 und 18:30Uhr alle 30 Minuten ausgeführt.
Achtung: 18:30 gehört auch noch dazu!

In der Praxis ist es oft einfacher mit sogenannten „Nicknames“ zu arbeiten. Hier eine kleine Liste der vorhandenen Nicknames, die man auch auf den Manpages findet:

@yearly – einmal im Jahr (0 0 1 1 *)
@annually – einmal im Jahr (0 0 1 1 *) – identisch mit @yearly
@monthly – jeweils am Ersten eines Monats (0 0 1 * *)
@weekly – jeden Sonntag um Mitternacht (0 0 * * 0)
@daily – täglich um Mitternacht (0 0 * * *)
@midnight – täglich um Mitternacht (0 0 * * *) – identisch mit @daily
@hourly – zu jeder vollen Stunde (0 * * * *)
@reboot – einmal nach dem Systemstart

Die eigene crontab-Datei kann man als root einfach mit

cat /etc/crontab

anschauen.

Kommando crontab

Die /etc/crontab wird nicht mit dem Kommando „crontab“ editiert. Wenn crontab als root gestartet wird, erstellt dieses eine crontab-Datei wie für jeden anderen Benutzer auch. Entsprechend muss /etc/crontab mit einem Editor bearbeitet werden.

Grundsätzlich können alle Benutzer das Kommando crontab verwenden und eigene Aufträge erstellen/editieren. Die benutzerspezifiscen crontab-Dateien werden zentral unter /var/spool/cron abgelegt.

Folgende Optionen unterstützt crontab:

  • -e (edit) editiert die crontab des angemeldeten Benutzers
  • -l (list) listet den Inhalt einer crontab-Datei auf
  • -r (remove) löscht die crontab-Datei eines Benutzers
  • -u (user) mit dieser Option kann Root die crontab eines anderen Benutzers bearbeiten oder einsehen

Berechtigungen

Die Authorisierungs-Dateien für cron liegen direkt im Verzeichnis /etc. Folgendes sollte beachtet werden:

  • cron.allow – sobald diese Datei existiert, dürfen nur Benutzer cron nutzen, die darin gelistet sind.
  • cron.deny – wenn diese Datei exisitert, jedoch keine cron.allow, dann dürfen alle Benutzer cron verwenden die nicht hier gelistet sind.
  • Existiert weder eine cron.allow noch eine cron.deny, dürfen alle Benutzer cron verwenden.
    ACHTUNG: Hier unterscheidet sich das Verhalten von cron zu „at“ – bei at darf bei fehlender at.allow und at.deny nur root den Dienst verwenden. Eine leere at.deny ermöglicht den Zugriff für alle Benutzer.

Wie auch an anderer Stelle auf dieser Blog-Seite möchte ich hier erwähnen, dass Kenntnisse zu den gezeigten Crontab-Felder für die LPIC-Prüfung besonders wichtig sind. Ich empfehle dringend, die Manpages zu crontab anzuschauen und selber ein paar Übungen zu machen.

Auf die Programme „anacron“, „fcron“ und „at“ gehe ich in separaten Artikeln ein. Unter GNU/Linux gibt es die Möglichkeit, Cron mit systemd zu ersetzen.

 

Flattr this!

Ein Gedanke zu „Cron und crond

  1. Pingback: Synology crond (Cron Daemon) | MG BLOG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.