Cron-Übersetzer:
was macht diese Zeile?

Jede Minute jeder Stunde, jeden Tag — 1 440 Läufe am Tag, 525 600 im Jahr. Alle fünf Felder sind Platzhalter, also ist nichts eingeschränkt. Für einen billigen Health-Ping ist das der richtige Zeitplan, für fast alles andere der falsche. Steht so eine geerbte Zeile vor einem teuren Skript, ist sie die erste, die Sie hinterfragen sollten.

Jeder 5. Wert dieses Feldes, gezählt ab seinem Minimum. Im Minutenfeld startet */5 bei :00, :05, :10 … :55 — 12-mal pro Stunde, immer zu denselben Minutenwerten. Es bedeutet nicht »5 Minuten nach dem letzten Lauf«: Cron gleicht Uhrzeitwerte ab. */7 ergibt darum :00, :07 … :56 und dann wieder :00 — eine Lücke von 4 Minuten zu jeder vollen Stunde.

Jeden Tag um Mitternacht, Serverzeit — Minute 0 der Stunde 0, jedes Datum, jeder Monat, jeder Wochentag. Genau diesen Zeitplan kürzt @daily ab. Gemeint ist die Mitternacht des Servers; in den Umstellungsnächten auf Sommer- oder Winterzeit kann eine Maschine mit lokaler Zeit den Lauf überspringen oder doppelt ausführen.

Identisch. Die Kurzformen entsprechen exakt: @hourly = 0 * * * *, @daily und @midnight = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. Aus der Reihe fällt @reboot — das ist überhaupt kein Zeitplan, es startet, sobald der Cron-Daemon hochfährt. Dieser Übersetzer schreibt die Kurzformen aus, sodass Sie immer die fünf Felder darunter sehen.

Weil er nicht aus einer crontab stammt. Quartz (Jenkins, Spring), manche Cloud-Scheduler und einige Cron-Bibliotheken stellen ein Sekundenfeld voran; damit sind es sechs — oder sieben mit angehängtem Jahr. Eine crontab installiert die Zeile nicht. Steht im Sekundenfeld eine 0, streichen Sie es; die übrigen fünf lesen sich meist als POSIX. Steht dort etwas anderes, feuert der Zeitplan öfter als einmal pro Minute — und das kann einfaches Cron überhaupt nicht ausdrücken.

Es ist Quartz für »kein bestimmter Wert«. Quartz verlangt, dass genau eines der beiden Tagesfelder ungenutzt bleibt, deshalb bekommt eines von ihnen ein Fragezeichen. POSIX-Cron kennt diese Regel nicht und kein ? — ein einfacher * genügt. Sind beide Tagesfelder tatsächlich eingeschränkt, läuft Cron an der Vereinigungsmenge der beiden. Fügen Sie ein ? in eine crontab ein, wird die Zeile abgewiesen.

Ja. Fügen Sie 30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 ein: Der Übersetzer nimmt die fünf Zeitplanfelder, übersetzt nur diese und benennt den Rest der Zeile als den Teil, den er ignoriert hat. Er liest auch die Form von /etc/crontab, bei der zwischen Zeitplan und Befehl ein Benutzername steht. Was er nicht tut: eine Zeile mit sechs Feldern erraten. Ein vorangestelltes Sekundenfeld bedeutet Quartz, nicht crontab, und das ist eine andere Sprache.

Fügen Sie den Ausdruck oben ein. Die Ergebnisansicht listet die nächsten zehn Läufe als konkrete Termine auf, berechnet von einem echten Parser in der Zeitzone Ihres Browsers. Die crontab selbst läuft nach der Uhr des Servers: Steht die Maschine auf UTC und Sie nicht, verschiebt sich die ganze Liste um Ihren Versatz. Nichts davon sagt Ihnen allerdings, ob ein Lauf erfolgreich war — Cron protokolliert nur, dass er gestartet ist.