Parser wyrażeń cron

Pięć pól oddzielonych spacjami albo skrót, na przykład @daily.

Przejmujesz plik crontab pełen wierszy w rodzaju 0 */2 * * 1-5 czy 30 3 * JAN,JUL 1. Ten parser rozkłada każde pole na dokładne wartości, które ono dopasowuje, więc zamiast zgadywać, co obejmuje */2, widzisz dwanaście wybranych godzin i ich liczbę tuż obok. Dostajesz też znormalizowaną postać z 5 polami, ostrzeżenie, gdy wyrażenie jest znaną pułapką, oraz 5 najbliższych uruchomień wyliczonych w Twojej własnej strefie czasowej.

Jak przeanalizować wyrażenie cron

  1. 1

    Wklej wyrażenie

    Wiersz z 5 polami (`* * * * *`): minuta, godzina, dzień miesiąca, miesiąc i dzień tygodnia. Działają też skróty takie jak `@daily`.

  2. 2

    Przeczytaj rozłożone pola

    Przy każdym polu widzisz pasujące wartości i ich liczbę, więc `*/2` w polu godziny pokazuje 0, 2, 4 i pozostałe dziewięć, które obejmuje.

  3. 3

    Sprawdź podgląd najbliższych uruchomień

    5 kolejnych terminów uruchomienia, obliczonych w Twojej przeglądarce według strefy czasowej Twojego urządzenia. Jeśli nie odpowiadają Twojemu zamiarowi, dopracuj wyrażenie.

  4. 4

    Przeczytaj ostrzeżenia

    Parser oznacza pułapki: oba pola dni ustawione naraz, datę, która nigdy nie nastąpi, albo operator, którego standardowy cron nie rozumie.

Na co rozkłada się każde pole

Pole to nie pojedyncza wartość, tylko zbiór. Wielkość tego zbioru zwykle wystarczy, aby odpowiedzieć na pytanie, z którym tu zaglądasz.

Pole Zakres * dopasowuje Uwagi
Minuta 0-59 60 wartości Najczęstsze źródło zadań wymykających się spod kontroli
Godzina 0-23 24 wartości Zegar 24-godzinny, nigdy 1-12
Dzień miesiąca 1-31 31 wartości Krótsze miesiące po prostu pomijają brakujące dni
Miesiąc 1-12 12 wartości Przyjmowane są także JAN do DEC
Dzień tygodnia 0-7 7 wartości 0 i 7 to w obu przypadkach niedziela

Operatory wewnątrz pola: * to każda wartość, 1,5,10 to lista, 1-5 to zakres, */15 to krok liczony od początku zakresu, a 0-45/15 to krok wewnątrz zakresu.

Nazwy i skróty są przyjmowane

Nazwy miesięcy i dni tygodnia są rozpoznawane i rozwijane do liczb, które dopasowują, więc dla 30 3 * JAN,JUL 1 parser podaje miesiąc 1, 7 i dzień tygodnia 1. Nazwane skróty są rozwijane do postaci z 5 polami, zanim zadzieje się cokolwiek innego:

Skrót Rozwija się do Znaczenie
@yearly, @annually 0 0 1 1 * Północ 1 stycznia
@monthly 0 0 1 * * Północ 1. dnia miesiąca
@weekly 0 0 * * 0 Północ w niedzielę
@daily, @midnight 0 0 * * * Północ każdego dnia
@hourly 0 * * * * Pełna godzina, co godzinę

@reboot też jest rozpoznawany, ale nie ma harmonogramu do rozwinięcia: uruchamia się raz, przy starcie maszyny, więc nie ma tu żadnych terminów do podejrzenia.

Ostrzeżenia, które warto przeczytać

  • Oba pola dni ograniczone. 0 0 1 * MON nie znaczy „1. dnia miesiąca, ale tylko wtedy, gdy wypada w poniedziałek”. Standardowy cron traktuje oba pola dni jako LUB, gdy oba są ograniczone, więc ten wiersz odpala się 1. dnia każdego miesiąca oraz w każdy poniedziałek. Parser zgłasza to ostrzeżenie, a podgląd uruchomień stosuje regułę LUB.
  • Data, która nigdy nie nastąpi. 0 0 30 2 * wskazuje 30 lutego. Wyrażenie jest składniowo poprawne i cron je przyjmie, ale nigdy się nie uruchomi. Parser mówi o tym wprost, zamiast pokazywać pustą listę bez żadnego wyjaśnienia.
  • Operatory Quartz. L (ostatni), W (najbliższy dzień roboczy), # (n-ty dzień tygodnia) oraz ? to rozszerzenia Quartz, a nie standardowy crontab. W wierszu z 5 polami są rozpoznawane i oznaczane, a pole pokazuje, że to operator Quartz, spoza standardowego crontab, zamiast listy wartości. Terminy uruchomień nie są obliczane, bo standardowy cron w ogóle nie wykonałby takiego wiersza.

Co jest odrzucane od razu

  • Błędna liczba pól. Wiersz Quartz z 6 polami (z sekundami) albo z 7 polami (z rokiem) jest odrzucany już na liczbie pól.
  • Wartości poza zakresem, na przykład minuta 75 albo miesiąc 13.
  • Zakres malejący, taki jak 5-1.
  • Krok zerowy, taki jak */0.

Każde odrzucenie wskazuje pole i wartość, która je spowodowała, więc poprawiasz jedną rzecz, zamiast przepisywać cały wiersz.

Strefa czasowa

Podgląd najbliższych uruchomień jest obliczany w Twojej przeglądarce, w strefie czasowej ustawionej na Twoim urządzeniu. Crontab działa w strefie czasowej maszyny, na której jest zainstalowany, więc jeśli ten serwer pracuje w UTC, a Ty nie, przesuń godziny odpowiednio, zanim je porównasz.

Najczęściej zadawane pytania

Nie jako harmonogram. Wiersz Quartz z 6 polami (z sekundami) albo z 7 polami (z rokiem) jest odrzucany już na liczbie pól. Operatory Quartz wewnątrz zwykłego wiersza z 5 polami (L, W, #, ?) to inny przypadek: są rozpoznawane i oznaczane, ale terminy uruchomień nie są obliczane, bo standardowy cron również nie wykonałby takiego wiersza.

Zwykle powodem jest różnica stref czasowych między Twoim urządzeniem a serwerem, który wykonuje crontab, albo ustawienie obu pól dni naraz. Gdy dzień miesiąca i dzień tygodnia są jednocześnie ograniczone, cron odpala zadanie, gdy pasuje którekolwiek z nich, a nie oba naraz (LUB, nie I), więc 0 0 1 * MON działa znacznie częściej, niż większość osób się spodziewa. Liczba wartości obok każdego pola to najszybszy sposób, aby wychwycić pole szersze, niż Ci się wydawało.

Tak. Kubernetes używa standardowej składni z 5 polami. Jedyne, co trzeba uwzględnić, to zegar: CronJob działa w strefie czasowej klastra (UTC, o ile spec.timeZone nie mówi inaczej), a podgląd tutaj korzysta ze strefy czasowej Twojego urządzenia.

To nazwane skróty, które cron w Linuksie przyjmuje zamiast pięciu pól. @daily (oraz @midnight) to 0 0 * * *, @weekly to 0 0 * * 0, @monthly to 0 0 1 * *, @yearly (oraz @annually) to 0 0 1 1 *, a @hourly to 0 * * * *. Wklej dowolny z nich, a parser pokaże postać z 5 polami, do której się rozwija. @reboot jest wyjątkiem: uruchamia się przy starcie systemu, więc nie ma harmonogramu ani terminów uruchomienia.

Powiązane narzędzia

Narzędzie jest dostępne w innych językach