cron - cron

Kommandolinjeverktøyet cron , også kjent som cron job, er en jobbplanlegger på Unix-lignende operativsystemer . Brukere som konfigurerer og vedlikeholder programvaremiljøer, bruker cron til å planlegge jobber (kommandoer eller skallskript ) for å kjøre med jevne mellomrom på faste tidspunkter, datoer eller intervaller. Det automatiserer vanligvis systemvedlikehold eller -administrasjon-selv om dets generelle formål gjør det nyttig for ting som å laste ned filer fra Internett og laste ned e-post med jevne mellomrom.

Cron er mest egnet for å planlegge repetitive oppgaver. Planlegging av engangsoppgaver kan utføres ved å bruke tilhørende på verktøyet.

Oversikt

Handlingene til cron drives av en crontab -fil (cron -tabell), en konfigurasjonsfil som spesifiserer skallkommandoer for å kjøre periodisk på en gitt tidsplan. Crontab -filene lagres der listene over jobber og andre instruksjoner til cron -demonen lagres. Brukere kan ha sine egne individuelle crontab-filer, og ofte er det en systemomfattende crontab-fil (vanligvis i /etceller en underkatalog av /etc) som bare systemadministratorer kan redigere.

Hver linje i en crontab -fil representerer en jobb, og ser slik ut:

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │                                   7 is also Sunday on some systems)
# │ │ │ │ │
# │ │ │ │ │
# * * * * * <command to execute>

Syntaksen for hver linje forventer et cron -uttrykk laget av fem felt som representerer tiden for kommandoen skal utføres, etterfulgt av en shell -kommando som skal utføres.

Selv om jobben normalt utføres når spesifikasjonene for tid/dato alle samsvarer med gjeldende klokkeslett og dato, er det ett unntak: hvis både "dag i måneden" (felt 3) og "ukedag" (felt 5) er begrenset ( ikke "*"), så må en eller begge samsvarer med gjeldende dag.

For eksempel sletter følgende Apache -feilloggen ett minutt over midnatt (00:01) hver dag, forutsatt at standardskallet for cron -brukeren er Bourne -skallkompatibelt :

1 0 * * * printf "" > /var/log/apache/error_log

Dette eksemplet kjører et skallprogram som heter export_dump.sh kl. 23.45 (23.45) hver lørdag.

45 23 * * 6 /home/oracle/scripts/export_dump.sh

Merk: Det er også mulig å spesifisere */nå kjøre for hvert n -tidsintervall. Du kan også angi flere spesifikke tidsintervaller med kommaer (f.eks. 1,2,3). Nedenstående sender ut "hei verden" til kommandolinjen hvert 5. minutt i hver første, andre og tredje time (dvs. 01:00, 01:05, 01:10, fram til 03:55).

*/5 1,2,3 * * * echo hello world

Konfigurasjonsfilen for en bruker kan redigeres ved å ringe crontab -euansett hvor den faktiske implementeringen lagrer denne filen.

Noen cronimplementeringer, for eksempel den populære 4. BSD -utgaven skrevet av Paul Vixie og inkludert i mange Linux -distribusjoner, legger til et sjette felt: et brukernavn for kontoen som kjører den angitte jobben (avhengig av brukerens eksistens og tillatelser). Dette er bare tillatt i systemkronene - ikke i andre, som hver er tilordnet en enkelt bruker å konfigurere. Det sjette feltet brukes alternativt noen ganger i år i stedet for et brukernavn for kontoen - nncron -demonen for Windows gjør dette.

Amazon EventBridge-implementeringen av cron bruker ikke 0 basert ukedag, i stedet er det 1-7 SUN-SAT (i stedet for 0-6), i tillegg til å støtte ytterligere uttrykksfunksjoner som første ukedag og siste dag i -måned.

Ikke -standard forhåndsdefinerte planleggingsdefinisjoner

Noen cron-implementeringer støtter følgende ikke-standardmakroer:

@rebootkonfigurerer en jobb som skal kjøres en gang når demonen startes. Siden cron vanligvis aldri startes på nytt, tilsvarer dette vanligvis at maskinen startes. Denne oppførselen håndheves i noen varianter av cron, for eksempel den som er gitt i Debian , slik at bare omstart av demonen ikke kjører @rebootjobber på nytt.

@rebootkan være nyttig hvis det er behov for å starte en server eller en demon under en bestemt bruker, og brukeren ikke har tilgang til å konfigurere init for å starte programmet.

Cron -tillatelser

Disse to filene spiller en viktig rolle:

• /etc/cron.allow - Hvis denne filen eksisterer, må den inneholde brukerens navn for at brukeren skal kunne bruke cron -jobber.
• /etc/cron.deny - Hvis cron.allow -filen ikke eksisterer, men /etc/cron.deny -filen eksisterer da, for å bruke cron -jobber, må brukerne ikke være oppført i /etc/cron.deny -filen.

Vær oppmerksom på at hvis ingen av disse filene eksisterer, kan bare superbrukeren bruke cron-jobber, eller alle brukere kan bruke cron-jobber, avhengig av nettstedavhengige konfigurasjonsparametere.

Tidssonehåndtering

De fleste cron -implementeringer tolker ganske enkelt crontab -oppføringer i systemets tidssoneinnstilling som cron -demonen kjører under. Dette kan være en kilde til tvist hvis en stor flerbrukermaskin har brukere i flere tidssoner, spesielt hvis systemets standard tidssone inkluderer den potensielt forvirrende sommertid . Dermed kan en cron -implementering som et spesielt tilfelle gjenkjenne linjer med formen "CRON_TZ = <tidssone>" i brukerens crontabs, og tolke påfølgende crontab -oppføringer i forhold til den tidssonen.

Historie

Tidlige versjoner

Cron i versjon 7 Unix var en systemtjeneste (senere kalt en demon ) påkalt fra /etc/rcda operativsystemet gikk inn i flerbrukermodus. Sin algoritme var enkel:

1. Lese /usr/lib/crontab
2. Bestem om noen kommandoer må kjøres på gjeldende dato og klokkeslett, og kjør dem i så fall som superbruker , root.
3. Sov i ett minutt
4. Gjenta fra trinn 1.

Denne versjonen av cron var grunnleggende og robust, men den brukte også ressurser på om den fant noe å gjøre eller ikke. I et eksperiment ved Purdue University på slutten av 1970-tallet for å utvide crons tjeneste til alle 100 brukere på en tidsdelt VAX , ble det funnet å belaste systemet for mye.

Mulighet for flere brukere

Den neste versjonen av cron, med utgivelsen av Unix System V , ble opprettet for å utvide funksjonene til cron til alle brukere av et Unix -system, ikke bare superbrukeren. Selv om dette kan virke trivielt i dag med de fleste Unix og Unix-lignende systemer som har kraftige prosessorer og et lite antall brukere, på den tiden krevde det en ny tilnærming til et one- MIPS- system med omtrent 100 brukerkontoer.

I utgaven av Communications of ACM i august 1977 publiserte WR Franta og Kurt Maly en artikkel med tittelen "En effektiv datastruktur for simuleringshendelsettet", som beskriver en datakonstruksjon for hendelseskø for diskrete hendelsesdrevne simuleringssystemer som demonstrerte " ytelse overlegen i forhold til vanlige enkle koblede liste-algoritmer ", god oppførsel gitt ujevne tidsfordelinger og kompleksitet i verste fall ," n "er antall hendelser i køen. ${\ displaystyle \ theta \ left ({\ sqrt {n}} \ right)}$

En doktorgradsstudent fra Purdue, Robert Brown, som gjennomgikk denne artikkelen, anerkjente parallellen mellom cron og diskrete hendelsessimulatorer , og opprettet en implementering av Franta - Maly event list manager (ELM) for eksperimentering. Diskrete hendelsessimulatorer kjører i virtuell tid , skreller hendelser av hendelseskøen så raskt som mulig og fremmer deres forestilling om "nå" til den planlagte tiden for den neste hendelsen. Å kjøre hendelsessimulatoren i "sanntid" i stedet for virtuell tid skapte en versjon av cron som brukte mesteparten av tiden på å sove og ventet på den planlagte tiden for å utføre oppgaven i spissen for hendelseslisten.

Det følgende skoleåret brakte nye studenter inn i utdanningsprogrammet på Purdue, inkludert Keith Williamson, som begynte i systempersonalet i datavitenskap. Som en "oppvarmingsoppgave" ba Brown ham om å bygge ut prototypen cron til en produksjonstjeneste, og denne flerbrukercronen ble tatt i bruk på Purdue i slutten av 1979. Denne versjonen av cron erstattet helt den /etc/cronsom var i bruk på datamaskinen vitenskapsavdelingens VAX 11/780 kjører 32/V.

Algoritmen som brukes av denne cron er som følger:

1. Når du starter, ser du etter en fil som er oppført .crontabi hjemmekatalogene til alle kontoinnehavere.
2. For hver crontab -fil som er funnet, må du bestemme neste gang hver kommando må kjøres.
3. Plasser disse kommandoene på hendelseslisten Franta - Maly med tilhørende tid og tidsspesifikatoren for "fem felt".
4. Skriv inn hovedsløyfe:
   1. Undersøk oppgaven i toppen av køen, beregne hvor langt den må kjøre i fremtiden.
   2. Sov i den perioden.
   3. Ved oppvåkning og etter å ha bekreftet riktig tid, utfør oppgaven i køen (i bakgrunnen) med rettighetene til brukeren som opprettet den.
   4. Bestem neste gang i fremtiden for å kjøre denne kommandoen og legg den tilbake på hendelseslisten til den aktuelle verdien.

I tillegg reagerer demonen på SIGHUP- signaler for å skanne endrede crontab-filer på nytt og planlegger spesielle "wake up events" i timen og en halv time for å lete etter modifiserte crontab-filer. Mange detaljer er utelatt her angående unøyaktighetene ved datamaskinens tidlige sporing, Unix-alarmplanlegging, eksplisitte endringer i dag og prosessstyring, som alle utgjør de fleste kodelinjene i denne cron. Denne cron fanget også opp utdataene fra stdout og stderr og sendte ut e-post til crontab-eieren.

Ressursene som forbrukes av denne cron -skalaen bare med mengden arbeid den får og øker ikke iboende over tid, med unntak av periodisk kontroll av endringer.

Williamson fullførte studiene og forlot universitetet med en Master of Science in Computer Science og begynte i AT&T Bell Labs i Murray Hill, New Jersey, og tok denne cron med seg. På Bell Labs innlemmet han og andre Unix- atkommandoen i cron, flyttet crontab-filene ut av brukernes hjemmekataloger (som ikke var vertsspesifikke) og inn i en felles vertsspesifikk spolkatalog, og nødvendigvis la crontabkommandoen til for å tillate brukere til å kopiere crontabs til den spool -katalogen.

Denne versjonen av cron dukket senere opp stort sett uendret i Unix System V og i BSD og deres derivater, Solaris fra Sun Microsystems , IRIX fra Silicon Graphics , HP-UX fra Hewlett-Packard og AIX fra IBM . Teknisk sett bør den opprinnelige lisensen for disse implementeringene være hos Purdue Research Foundation som finansierte arbeidet, men dette skjedde i en tid da det ble gitt liten bekymring for slike saker.

Moderne versjoner

Med ankomsten av GNU -prosjektet og Linux dukket det opp nye crons. Den mest utbredte av disse er Vixie cron, opprinnelig kodet av Paul Vixie i 1987. Versjon 3 av Vixie cron ble utgitt i slutten av 1993. Versjon 4.1 ble omdøpt til ISC Cron og ble utgitt i januar 2004. Versjon 3, med noen mindre feilrettinger , brukes i de fleste distribusjoner av Linux og BSD.

I 2007 gaffel Red Hat vixie-cron 4.1 til cronie- prosjektet og inkluderte anacron 2.3 i 2009.

Andre populære implementeringer inkluderer anacron og dcron. Anacron er imidlertid ikke et uavhengig cron -program. En annen cron -jobb må kalle det. dcron ble laget av DragonFly BSD -grunnlegger Matt Dillon , og vedlikeholdet ble overtatt av Jim Pryor i 2010.

I 2003 introduserte Dale Mellor mcron, en cron-variant skrevet i Guile som gir krysskompatibilitet med Vixie cron, samtidig som den gir større fleksibilitet ettersom den tillater at vilkårlig skjemakode brukes i planleggingsberegninger og jobbdefinisjoner. Siden både mcron -demonen og crontab -filene vanligvis er skrevet i skjema (selv om mcron også godtar tradisjonelle Vixie crontabs), er den kumulative tilstanden til en brukers jobbkø tilgjengelig for jobbkoden , som kan være planlagt å kjøre iff resultatene av andre jobber oppfyller visse kriterier. Mcron distribueres som standard under Guix -pakkebehandleren , som inkluderer bestemmelser ( tjenester ) for pakkebehandleren til monadisk å avgi mcron -crontabs, samtidig som de sikrer at pakker som trengs for jobbutførelse er installert, og at de tilsvarende crontabene refererer til dem korrekt.

En webcron -løsning planlegger ringoppgaver som skal kjøres regelmessig uansett hvor cron -implementeringer ikke er tilgjengelige i et webhotellmiljø .

CRON -uttrykk

Et CRON -uttrykk er en streng som består av fem eller seks felt atskilt med hvitt mellomrom som representerer et sett med ganger, vanligvis som en plan for å utføre en rutine.

Kommentarer begynner med et merkemerke #, og må stå på en linje alene.

Måned og ukedag forkortelser er ikke store og små bokstaver.

I det spesielle tilfelle med systemet crontab (/ etc / crontab), en bruker felt innsatser seg før kommandoen . Det er vanligvis satt til 'root'.

I noen bruksområder av CRON -formatet er det også et sekundfelt i begynnelsen av mønsteret. I så fall er CRON -uttrykket en streng som består av 6 eller 7 felt.

Komma ( ,)

Komma brukes til å skille elementer fra en liste. For eksempel å bruke "MON, WED, FRI" i det femte feltet (ukedag) betyr mandager, onsdager og fredager.

Dash ( -)

Dash definerer områder. For eksempel angir 2000–2010 hvert år mellom 2000 og 2010, inkludert.

Prosent ( %)

Prosenttegn ( %) i kommandoen, med mindre de slipper unna med omvendt skråstrek (\), endres til nye linjetegn, og alle data etter de første % sendes til kommandoen som standardinngang.

Ikke-standardtegn

Følgende er ikke-standardtegn og finnes bare i noen cron-implementeringer, for eksempel Quartz Java-planleggeren .

L

'L' står for "siste". Når den brukes i feltet ukedag, tillater det å spesifisere konstruksjoner som "den siste fredagen" (" 5L ") i en gitt måned. I feltet månedlig måned angir den siste dag i måneden.

W

"W" -tegnet er tillatt for feltet i månedsdagen. Dette tegnet brukes til å angi ukedagen (mandag-fredag) nærmest den gitte dagen. For eksempel, hvis " 15W " er spesifisert som verdien for månedsfeltet, er betydningen: "den nærmeste ukedagen til den 15. i måneden." Så hvis den 15. er en lørdag, utløses utløseren fredag ​​den 14.. Hvis den 15. er en søndag, utløses utløseren mandag den 16. Hvis den 15. er en tirsdag, avfyres den tirsdag den 15.. Men hvis "1W" er angitt som verdien for månedsdagen, og den første er en lørdag, utløses utløseren mandag den 3., siden den ikke "hopper" over grensen til en måneds dager. W-tegnet kan bare spesifiseres når månedsdagen er en enkelt dag, ikke et område eller en liste over dager.

Hash ( #)

'#' er tillatt for feltet ukedag, og må følges av et tall mellom en og fem. Den tillater spesifisering av konstruksjoner som "den andre fredagen" i en gitt måned. Hvis du for eksempel angir "5#3" i feltet ukedag, tilsvarer den tredje fredagen i hver måned.

Spørsmålstegn ( ?)

I noen implementeringer, brukt i stedet for " * " for å la hver dag i måneden eller ukedagen stå tom. Andre cron -implementeringer erstatter "?" med oppstartstidspunktet for cron-demonen, slik at den ? ? * * * *vil bli oppdatert til 25 8 * * * *hvis cron startet opp 8:25, og ville kjøre på dette tidspunktet hver dag til den ble startet på nytt.

Slash ( /)

I vixie-cron kan skråstreker kombineres med områder for å angi trinnverdier. For eksempel angir */5 i minuttfeltet hvert 5. minutt (se merknad nedenfor om frekvenser). Det er stenografi for den mer oversiktlige POSIX -skjemaet 5,10,15,20,25,30,35,40,45,50,55,00 . POSIX definerer ikke bruk for skråstreker; dens begrunnelse (kommentar til en BSD -utvidelse) bemerker at definisjonen er basert på System V -format, men utelukker ikke muligheten for utvidelser.

Vær oppmerksom på at frekvenser generelt ikke kan uttrykkes; bare trinnverdier som jevnt deler sitt område uttrykker nøyaktige frekvenser (i minutter og sekunder, det er /2, /3, /4, /5, /6, /10, /12, /15, /20 og /30 fordi 60 er deles jevnt med disse tallene; i timer, det er /2, /3, /4, /6, /8 og /12 ); alle andre mulige "trinn" og alle andre felt gir inkonsekvente "korte" perioder på slutten av tidsenheten før den "tilbakestilles" til neste minutt, sekund eller dag; for eksempel, angir */5 for dagsfeltet noen ganger etter 1, 2 eller 3 dager, avhengig av måned og skuddår; dette er fordi cron er statsløs (den husker ikke tidspunktet for den siste henrettelsen eller teller forskjellen mellom den og nå, nødvendig for nøyaktig frekvenstelling-i stedet er cron bare et mønster-matcher).

H

'H' brukes i Jenkins kontinuerlige integrasjonssystem for å indikere at en "hash" verdi er erstattet. I stedet for et fast tall som ' 20 * * * *' som betyr 20 minutter etter timen hver time, ' H * * * *' indikerer således at oppgaven utføres hver time på et uspesifisert, men uforanderlig tidspunkt for hver oppgave. Dette gjør det mulig å spre oppgaver over tid, i stedet for at alle starter samtidig og konkurrerer om ressurser.

Se også

• på (kommando)
• Lansert
• Liste over Unix -kommandoer
• Planlegging (databehandling)
• systemd - inneholder cron -ekvivalent (kalt tidtakere )
• fcron
• Oppgaveplanlegger for Windows

Referanser

Eksterne linker

• crontab: planlegge periodisk bakgrunnsarbeid - Kommandoer og verktøyreferanse, UNIX -spesifikasjonen , utgave 7 fra The Open Group
• GNU cron (mcron)
• ISC Cron 4.1
• cronie
• ACM digitalt bibliotek - Franta, Maly, "En effektiv datastruktur for settet med simuleringshendelser" (krever abonnement på ACM -puber)
• Crontab syntaksopplæring - forklart Crontab syntaks
• UNIX / Linux cron -opplæring - en rask opplæring for UNIX -lignende operativsystemer med eksempler på skallskript.