0 0 * * * lässt den Auftrag einmal täglich um Mitternacht laufen, also um 0:00 Uhr – in der ersten Minute des neuen Tages, nicht in der letzten des alten. Minute und Stunde stehen auf null, Tag, Monat und Wochentag bleiben offen. Die Kurzformen @daily und @midnight meinen dieselbe Zeile.
Zu welchem Tag gehört der Mitternachtslauf?
Zum neuen. Ein Auftrag, der am Dienstag um 0:00 Uhr startet, sieht das Datum des Dienstags. Eine Auswertung, die den Montag zusammenfassen soll, muss also ausdrücklich einen Tag abziehen, etwa mit date -d yesterday. Dieser eine Versatz erzeugt mehr leere Berichte als jeder andere Cron-Fehler, denn das Skript läuft fehlerfrei und sieht nur auf einen Tag, der kaum begonnen hat.
Ist Mitternacht ein guter Zeitpunkt für Sicherungen?
Es ist der vollste Zeitpunkt auf den meisten Maschinen: Log-Rotation, Datenbank-Abzüge, Aufräumaufträge und die halbe Welt starten um 0:00 Uhr. Wenn deine Sicherung mit all dem konkurriert, dauert sie länger und trifft eher auf eine gesperrte Datei. Ein Wechsel auf 2:30 oder 3:15 Uhr bringt meist ein ruhigeres Fenster, ohne einen Nachteil.
Was, wenn die Maschine um Mitternacht aus ist?
Klassisches Cron lässt den Lauf einfach ausfallen; es merkt sich verpasste Aufträge nicht. Laptops und Büro-Rechner brauchen deshalb anacron, das den letzten erfolgreichen Lauf festhält und nach dem Hochfahren nachholt, oder einen systemd-Timer mit Persistent=true. Auf einem durchlaufenden Server spielt das keine Rolle – und genau deshalb überrascht es alle, die einen Auftrag auf einen Arbeitsplatzrechner verschieben.
So trägst du den Ausdruck ein
- Zuerst klären, ob der Auftrag die Daten von gestern braucht; wenn ja, das Datum im Skript berechnen statt sich auf den Lauftag zu verlassen.
- Die Zeile 0 0 * * * samt Befehl eintragen – oder @daily, wenn die Datei ohnehin nur von Menschen gelesen wird.
- Bei einem schweren Auftrag über eine ruhigere Zeit wie 0 2 * * * nachdenken.
- Start- und Endzeit protokollieren, damit später erkennbar ist, ob ein Lauf ausgefallen ist.