Parser för cron-uttryck

Fem fält separerade med mellanslag, eller en förkortning som @daily.

Du ärver en crontab full av rader som 0 */2 * * 1-5 och 30 3 * JAN,JUL 1. Den här parsern expanderar varje fält till exakt de värden det matchar, så i stället för att gissa vad */2 täcker ser du de tolv timmar det väljer ut och antalet bredvid dem. Du får också den normaliserade formen med 5 fält, en varning när uttrycket är en känd fälla och de 5 nästa körtiderna uträknade i din egen tidszon.

Så tolkar du ett cron-uttryck

  1. 1

    Klistra in uttrycket

    En rad med 5 fält (`* * * * *`): minut, timme, dag i månaden, månad och veckodag. Förkortningar som `@daily` fungerar också.

  2. 2

    Läs de expanderade fälten

    Varje fält listas med de värden det matchar och hur många de är, så `*/2` i timfältet visar 0, 2, 4 och de nio övriga timmar det täcker.

  3. 3

    Kontrollera förhandsvisningen av nästa körningar

    5 kommande körtider, beräknade i din webbläsare utifrån din egen tidszon. Stämmer de inte med din avsikt, justera uttrycket.

  4. 4

    Läs varningarna

    Parsern flaggar fällorna: båda dagfälten angivna, ett datum som aldrig kan inträffa eller en operator som vanlig cron inte förstår.

Vad varje fält expanderas till

Ett fält är inte ett enskilt värde, det är en mängd. Att veta hur stor den mängden är besvarar oftast frågan du kom hit med.

Fält Intervall * matchar Att tänka på
Minut 0-59 60 värden Den vanligaste källan till jobb som körs alldeles för ofta
Timme 0-23 24 värden 24-timmarsklocka, aldrig 1-12
Dag i månaden 1-31 31 värden Korta månader hoppar helt enkelt över dagarna som saknas
Månad 1-12 12 värden JAN till DEC fungerar också
Veckodag 0-7 7 värden Både 0 och 7 är söndag

Operatorer inuti ett fält: * varje värde, 1,5,10 en lista, 1-5 ett intervall, */15 ett steg räknat från början av intervallet och 0-45/15 ett steg inom ett intervall.

Namn och förkortningar accepteras

Namn på månader och veckodagar tolkas och expanderas till de siffror de matchar, så 30 3 * JAN,JUL 1 redovisar månad 1, 7 och veckodag 1. De namngivna förkortningarna expanderas till sin form med 5 fält innan något annat händer:

Förkortning Expanderas till Betydelse
@yearly, @annually 0 0 1 1 * Midnatt den 1 januari
@monthly 0 0 1 * * Midnatt den 1:a i månaden
@weekly 0 0 * * 0 Midnatt på söndagar
@daily, @midnight 0 0 * * * Midnatt varje dag
@hourly 0 * * * * Varje heltimme

@reboot känns också igen, men det har inget schema att expandera: det körs en gång när maskinen startar, så det finns inga körtider att förhandsvisa.

Varningar värda att läsa

  • Båda dagfälten begränsade. 0 0 1 * MON betyder inte ”den 1:a, men bara om det är en måndag”. Vanlig cron behandlar de två dagfälten som ELLER när båda är begränsade, så den raden körs den 1:a varje månad och varje måndag. Parsern visar den varningen, och förhandsvisningen av körtiderna följer ELLER-regeln.
  • Ett datum som aldrig inträffar. 0 0 30 2 * begär 30 februari. Uttrycket är syntaktiskt giltigt och cron accepterar det, men det kommer aldrig att köras. Parsern säger det i stället för att visa en tom lista utan förklaring.
  • Quartz-operatorer. L (sista), W (närmaste vardag), # (n:te veckodagen) och ? är tillägg från Quartz, inte vanlig crontab. Inuti en rad med 5 fält känns de igen och flaggas, och fältet visar att det är en Quartz-operator i stället för en lista med värden. Inga körtider beräknas, eftersom vanlig cron inte skulle köra den raden alls.

Vad som avvisas direkt

  • Fel antal fält. En Quartz-rad med 6 fält som har sekunder, eller en rad med 7 fält som har år, avvisas på antalet fält.
  • Värden utanför intervallet, till exempel minut 75 eller månad 13.
  • Ett intervall som går baklänges, till exempel 5-1.
  • Ett steg på 0, till exempel */0.

Varje avvisning pekar ut fältet och värdet som orsakade den, så att du kan rätta en sak i stället för att skriva om hela raden.

Tidszon

Förhandsvisningen av nästa körningar beräknas i din webbläsare, i den tidszon som din enhet är inställd på. En crontab körs i tidszonen på maskinen som kör den, så om servern går på UTC och du inte gör det, räkna om tiderna innan du jämför: svensk tid ligger en timme före UTC på vintern och två timmar före på sommaren.

Vanliga frågor

Inte som ett schema. En Quartz-rad med 6 fält som har sekunder, eller en med 7 fält som har år, avvisas på antalet fält. Quartz-operatorer inuti en vanlig rad med 5 fält (L, W, #, ?) är ett annat fall: de känns igen och flaggas, men inga körtider beräknas, eftersom vanlig cron inte heller skulle köra den raden.

De vanliga orsakerna är en tidszonsskillnad mellan din enhet och servern som kör din crontab, eller att båda dagfälten är angivna. När både dag i månaden och veckodag är begränsade körs jobbet när något av dem matchar, inte båda, så 0 0 1 * MON körs betydligt oftare än de flesta väntar sig. Antalet värden bredvid varje fält är det snabbaste sättet att upptäcka ett fält som är bredare än du trodde.

Ja. Kubernetes använder vanlig syntax med 5 fält. Det enda du behöver justera för är klockan: ett CronJob körs i klustrets tidszon (UTC om inte spec.timeZone säger något annat), medan förhandsvisningen här utgår från tidszonen på din egen enhet.

Det är namngivna förkortningar som Linux-cron accepterar i stället för fem fält. @daily (även @midnight) är 0 0 * * *, @weekly är 0 0 * * 0, @monthly är 0 0 1 * *, @yearly (även @annually) är 0 0 1 1 * och @hourly är 0 * * * *. Klistra in vilken som helst av dem, så visar parsern formen med 5 fält som den expanderas till. @reboot är undantaget: det körs vid uppstart, så det har inget schema och inga körtider.

Relaterade verktyg

Verktyget finns på andra språk