* * * * *Felder
| Minute | * | beliebig |
|---|---|---|
| Stunde | * | beliebig |
| Tag des Monats | * | beliebig |
| Monat | * | beliebig |
| Wochentag | * | beliebig |
Wo du ihn verwendest
| crontab | * * * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "* * * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "* * * * *" |
crontab läuft in der Zeitzone des Servers; GitHub Actions verwendet immer UTC.
Gut zu wissen
Jede Minute ist die feinste Auflösung, die Standard-cron bietet; für alles Schnellere nutze eine Schleife im Skript, einen zweiten Eintrag, der mit sleep 30 beginnt, oder einen systemd-Timer. Die größte Falle ist Überlappung: Dauert ein Lauf länger als eine Minute, stapeln sich die Kopien. Kapsle den Job in flock, zum Beispiel flock -n /tmp/job.lock /path/to/script.sh, damit ein neuer Lauf sich sofort beendet, solange der vorherige noch läuft.
Cron läuft mit einer minimalen Umgebung: PATH ist meist nur /usr/bin:/bin, es wird kein Shell-Profil geladen, und das Arbeitsverzeichnis ist dein Home-Ordner, also nutze absolute Pfade. Die Ausgabe wird an den Benutzer gemailt oder verworfen, also leite sie mit >> /var/log/job.log 2>&1 um und rotiere dieses Log. GitHub Actions läuft nicht so oft: Das kürzeste Intervall dort sind 5 Minuten. Ein schonenderer Nachbar ist */2, alle zwei Minuten.