Hva er et cron-uttrykk? Syntaks, felt og 15 eksempler

Et cron-uttrykk er en kort tekststreng som forteller en planlegger når en jobb skal kjøres. Standardformen har fem felt atskilt med mellomrom: minutt, time, dag i måneden, måned og ukedag. For eksempel betyr */15 * * * * «hvert 15. minutt»: */15 i minuttfeltet treffer minuttene 0, 15, 30 og 45, og de fire stjernene betyr hvilken som helst time, dag, måned og ukedag.

Prøv gratis: Crontab-generator Gratis å bruke, ingen konto nødvendig.

Navnet kommer fra cron, jobbplanleggeren i Unix, men den samme syntaksen styrer i dag også CI-pipelines, skyplanleggere og applikasjonsrammeverk, noen ganger med ekstra felt. Denne guiden forklarer syntaksen, 15 kontrollerte eksempler, de vanligste variantene og feilene som får en jobb til å kjøre til feil tid. Vil du sjekke et uttrykk mens du leser, kan du lime det inn i den gratis Crontab-generatoren, som beskriver tidsplanen med vanlige ord.

De fem feltene i et cron-uttrykk

Feltene leses fra venstre mot høyre:

Timene angis med 24-timersklokke, så kl. 14 skrives 14. Navnene er de tre første bokstavene i det engelske navnet på måneden eller dagen, og det spiller ingen rolle om de skrives med store eller små bokstaver. Noen implementasjoner, blant dem cron på macOS, godtar ikke navn i intervaller eller lister, så 1-5 er mer portabelt enn mon-fri.

I en crontab-fil kommer kommandoen etter de fem feltene: 0 2 * * * /home/me/backup.sh. Den systemomfattende /etc/crontab på Linux har i tillegg et felt for brukernavn foran kommandoen.

Spesialtegn: stjerne, komma, bindestrek og skråstrek

Fire tegn gjør nesten hele jobben:

De kan kombineres. 9-17/2 i timefeltet treffer 9, 11, 13, 15 og 17, og 0-4,8-12 er en liste med to intervaller.

Steg starter på nytt i hver syklus. */7 i minuttfeltet treffer 0, 7, 14 … 56 og så 0 igjen ved starten av neste time, så mellom :56 og :00 går det fire minutter, ikke sju. Et steg som ikke går opp i 60 minutter eller 24 timer, gir aldri et helt jevnt intervall.

15 eksempler på cron-uttrykk

Hvert eksempel er kontrollert felt for felt. Tidene gjelder i planleggerens tidssone.

To detaljer er lette å overse. For det første tar intervaller med begge endepunktene, så 9-17 inkluderer time 17: */15 9-17 * * 1-5 kjører 36 ganger om dagen, og siste kjøring er kl. 17:45, ikke 17:00. For det andre gir 0 0 1 */3 * den samme kvartalsplanen, fordi */3 i månedsfeltet starter på 1 og treffer månedene 1, 4, 7 og 10.

Makroer utenfor standarden: @daily, @weekly og @reboot

Mange cron-implementasjoner godtar et nøkkelord i stedet for de fem feltene:

Vixie cron, cronie og cron på macOS støtter alle sammen, og CronJobs i Kubernetes godtar de tidsbaserte, men ikke @reboot. De er ikke en del av POSIX-standarden, så sjekk dokumentasjonen før du bruker dem andre steder.

Cron-varianter: sekunder, år og ekstra tegn

Ikke alle planleggere leser fem felt, så sjekk hvilken dialekt du skriver for.

• Quartz (Java) bruker seks eller sju felt: sekunder, minutter, timer, dag i måneden, måned, ukedag og et valgfritt år. Ett av de to dagfeltene må være ? («ingen bestemt verdi»). Quartz støtter også L (siste), W (nærmeste ukedag) og # (n-te ukedag i måneden): 0 15 10 L * ? kjører kl. 10:15 den siste dagen i hver måned, og 0 15 10 ? * 6#3 kjører kl. 10:15 den tredje fredagen, fordi Quartz nummererer ukedagene 1–7 med søndag først.
• Spring-uttrykk i @Scheduled(cron = "…") har seks felt: sekunder først, deretter de vanlige fem, uten år.
• Regler i AWS EventBridge bruker cron(minutes hours day-of-month month day-of-week year): seks felt, ingen sekunder, år til slutt og ? i ett av de to dagfeltene. cron(0 12 * * ? *) kjører hver dag kl. 12:00 UTC. Regler på en hendelsesbuss kjører i UTC, mens EventBridge Scheduler lar deg velge tidssone. I likhet med Quartz nummererer AWS ukedagene 1–7 med 1 = søndag.
• CronJobs i Kubernetes bruker de fem standardfeltene i spec.schedule. Uten spec.timeZone følger tidsplanen tidssonen til kube-controller-manager. Sett feltet til et IANA-navn som Europe/Berlin for å låse det.
• schedule-utløsere i GitHub Actions bruker fem felt og kjører i UTC med mindre du angir en valgfri IANA-tidssone. Det korteste støttede intervallet er hvert femte minutt, makroer som @daily støttes ikke, og planlagte kjøringer kan starte for sent når GitHub har høy belastning, særlig ved hel time.

Fellen med dag i måneden og ukedag

I standard-cron (Vixie) kombineres de to dagfeltene med ELLER, ikke OG, når begge er begrenset. Er ett av dem *, teller bare det andre. Derfor betyr ikke 0 9 1-7 * 1 «første mandag i måneden». Jobben kjører kl. 09:00 hver av dagene 1 til 7 og i tillegg hver mandag, til sammen 10 eller 11 ganger i måneden.

Skal den bare kjøre første mandag, beholder du ett dagfelt i uttrykket og sjekker det andre i kommandoen:

0 9 1-7 * * [ "$(date +\%u)" = 1 ] && /path/to/report.sh

date +%u skriver ut ukedagen som et tall fra 1 til 7, der mandag = 1. Prosenttegnet må skrives som \%, fordi cron gjør et % uten skråstrek i kommandoen om til et linjeskift. Quartz og AWS unngår tvetydigheten ved å kreve ? i ett av de to dagfeltene.

Tidssoner og sommertid

Cron kjører i tidssonen til maskinen eller tjenesten som tolker uttrykket, og på servere og skyplattformer er det ofte UTC, ikke din lokale tid. 0 9 * * * på en UTC-server kjører kl. 09:00 UTC, altså kl. 11:00 i Oslo om sommeren (UTC+2). Med tidssonekonvertereren kan du regne om en lokal tid til planleggerens tidssone.

Sommertid gir to spesialtilfeller i tidssoner som bruker det: Når klokken stilles frem, finnes én lokal time ikke, og når den stilles tilbake, forekommer én time to ganger. Cron i Debian og cronie kompenserer for små klokkeendringer for jobber med fast klokkeslett: En kjøring som faller i den hoppede timen, skjer kort tid etter omstillingen, og en kjøring i den gjentatte timen blir ikke gjentatt. Andre planleggere oppfører seg annerledes, så det tryggeste er å kjøre servere i UTC eller holde viktige jobber unna timene da klokken stilles, vanligvis mellom 01:00 og 03:00 lokal tid.

Slik tester du et cron-uttrykk

Et feil cron-uttrykk gir sjelden en feilmelding. Jobben kjører bare til feil tid, eller aldri. En kort rutine fanger opp de fleste problemene:

1. Les det tilbake med ord. Lim inn uttrykket i et verktøy som beskriver det, og sjekk at setningen stemmer med det du mente, særlig for de to dagfeltene.
2. Test kommandoen med en kort tidsplan. Bruk * * * * * midlertidig, så jobben kjører innen ett minutt, og bytt deretter til den ekte tidsplanen.
3. Ta vare på utdataene. Legg til >> /tmp/myjob.log 2>&1 etter kommandoen, så feil skrives til en fil i stedet for å forsvinne.
4. Sjekk cron-loggen. Bruk grep CRON /var/log/syslog eller journalctl -u cron på Debian og Ubuntu, og journalctl -u crond på Fedora og RHEL.
5. Bruk absolutte stier. Cron starter jobber med et minimalt miljø og en kort PATH, så en kommando som virker i terminalen, kan feile under cron.

Lag et uttrykk med Crontab-generatoren

Den gratis Crontab-generatoren kjører helt i nettleseren din. Skriv inn et uttrykk eller klikk på et hurtigvalg som «Hvert 15. min», «Daglig kl. 02» eller «Hver mandag», så gjør verktøyet følgende:

• validerer syntaksen og sier fra når et uttrykk er ugyldig;
• beskriver tidsplanen med vanlige ord (på engelsk);
• godtar de fem standardfeltene, et valgfritt sekundfelt først, navn på måneder og ukedager og 7 for søndag;
• gjør om makroer som @weekly til tilsvarende uttrykk med fem felt og forklarer hva @reboot gjør;
• viser en oversikt over alle symbolene med et eksempel på hvert.

Med brytere velger du en mer detaljert beskrivelse, 24-timersformat og om ukedagstallene skal starte på 0 for søndag. Tegn som bare finnes i Quartz (L, W, #), og et årsfelt godtas ikke. Verktøyet bygger og kontrollerer bare uttrykket. For å planlegge jobben kopierer du det inn i crontab -e eller i konfigurasjonen til plattformen din.

Vanlige spørsmål

Hva er forskjellen på cron og crontab?

Cron er bakgrunnstjenesten (daemonen) som kjører planlagte jobber. En crontab, kort for «cron table», er filen som lister dem opp, én jobb per linje: et cron-uttrykk fulgt av en kommando. Din egen crontab redigerer du med crontab -e og viser med crontab -l.

Kan en cron-jobb kjøre hvert 30. sekund?

Ikke i standard-cron, der den minste enheten er ett minutt. Planleggere med sekundfelt kan det: Spring godtar */30 * * * * *, og Quartz trenger ? i ett dagfelt, som i */30 * * * * ?. Med klassisk cron er en vanlig løsning to linjer som begge kjører hvert minutt, der den ene kjører sleep 30; før kommandoen.

Hvordan kjører jeg en cron-jobb den siste dagen i måneden?

Standard-cron har ikke noe tegn for «siste dag», men Quartz og AWS støtter L i feltet for dag i måneden. I klassisk cron planlegger du dagene 28 til 31 og lar kommandoen sjekke om i morgen er den 1.:

0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /path/to/job.sh

date -d tomorrow er syntaks for GNU date, slik den finnes på Linux. På macOS bruker du date -v+1d i stedet.

Prøv gratis: Crontab-generator Gratis å bruke, ingen konto nødvendig.