* * * * *Pola
| Minuta | * | dowolna |
|---|---|---|
| Godzina | * | dowolna |
| Dzień miesiąca | * | dowolna |
| Miesiąc | * | dowolna |
| Dzień tygodnia | * | dowolna |
Gdzie go użyć
| crontab | * * * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "* * * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "* * * * *" |
crontab działa w strefie czasowej serwera; GitHub Actions zawsze używa UTC.
Warto wiedzieć
Co minutę to najdrobniejsza rozdzielczość, jaką oferuje standardowy cron; jeśli potrzebujesz częściej, użyj pętli w skrypcie, drugiego wpisu zaczynającego się od sleep 30 albo timera systemd. Główna pułapka to nakładanie się uruchomień: jeśli przebieg trwa dłużej niż minutę, kopie się piętrzą. Opakuj zadanie we flock, np. flock -n /tmp/job.lock /path/to/script.sh, żeby nowe uruchomienie kończyło się od razu, gdy poprzednie wciąż trwa.
Cron działa w minimalnym środowisku: PATH to zwykle tylko /usr/bin:/bin, żaden profil powłoki nie jest wczytywany, a bieżącym folderem jest Twój folder domowy, więc używaj ścieżek bezwzględnych. Wyjście jest wysyłane mailem do użytkownika albo odrzucane, więc przekieruj je przez >> /var/log/job.log 2>&1 i rotuj ten log. GitHub Actions nie uruchomi zadania tak często: jego najkrótszy interwał to 5 minut. Łagodniejsza alternatywa to */2, czyli co dwie minuty.