Share
Cron Jobs brukes til å planlegge oppgaver for å kjøre på serveren. De er oftest brukt til å automatisere systemvedlikehold eller administrasjon. Men de er også relevante for utvikling av webapplikasjoner. Det er mange situasjoner når et webprogram kan trenge visse oppgaver å kjøre regelmessig. I dag skal vi utforske grunnleggende for Cron Jobs.
Først må vi gjøre oss kjent med betingelsene knyttet til dette emnet.
"Cron" er en tidsbasert jobbplanlegger i Unix-lignende operativsystemer (Linux, FreeBSD, Mac OS etc ...). Og disse jobbene eller oppgavene refereres til som "Cron Jobs".
Det er en cron "daemon" som kjører på disse systemene. En demon er et program som kjører i bakgrunnen hele tiden, vanligvis startet av systemet. Denne cron-demonen er ansvarlig for å lansere disse cron-jobbene på skjema.
Tidsplanen ligger i en konfigurasjonsfil med navnet "crontab". Det er her alle oppgavene og deres timere er oppført.
Serveradministratorer har lenge brukt cron-jobber. Men siden målgruppen i denne artikkelen er webutviklere, la oss se på noen brukssaker av cron-jobber som er relevante i dette området:
Her er en enkel cron jobb:
10 * * * * / usr / bin / php /www/virtual/username/cron.php> / dev / null 2> & 1
Det er to hoveddeler:
Kommandoen selv i dette eksemplet har tre deler:
Dette er den første delen av cron-arbeidsstrengen, som nevnt ovenfor. Det avgjør hvor ofte og når cron-jobben skal løpe.
Den består av fem deler:
Her er en illustrasjon:
Ganske ofte vil du se en stjerne (*) i stedet for et tall. Dette representerer alle mulige tall for den posisjonen. For eksempel vil stjerne i minuttposisjonen få det til å løpe hvert minutt.
Vi må se på noen få eksempler for å forstå denne syntaksen fullt ut.
Denne cron-jobben vil løpe hvert minutt hele tiden:
* * * * * [kommando]
Denne cron-jobben vil kjøre i minuttet null, hver time (dvs. en time-cron-jobb):
0 * * * * [kommando]
Dette er også en time-cron-jobb, men kjøre i minuttet 15 i stedet (dvs. 00:15, 01:15, 02:15 etc.):
15 * * * * [kommando]
Dette vil løpe en gang om dagen, klokken 2:30:
30 2 * * * [kommando]
Dette vil løpe en gang i måneden, den andre dagen i måneden ved midnatt (dvs. 2. januar kl 12:00, 2. februar kl 12:00)
0 0 2 * * [kommando]
Dette vil løpe på mandager, hver time (det vil si 24 ganger på en dag, men bare på mandager):
0 * * * 1 [kommando]
Du kan bruke flere tall separert med kommaer. Dette vil løpe tre ganger hver time, i minutter 0, 10 og 20:
0,10,20 * * * * [kommando]
Divisjon operatør er også brukt. Dette vil løpe 12 ganger i timen, det vil si hvert 5. minutt:
* / 5 * * * * [kommando]
Dash kan brukes til å spesifisere et område. Dette vil løpe en gang hver time mellom 5:00 og 10:00:
0 5-10 * * * [kommando]
Også det er et spesielt søkeord som lar deg kjøre en cron jobb hver gang serveren startes på nytt:
@reboot [kommando]
Det er noen forskjellige måter å opprette og administrere dine cron-jobber.
Mange web hosting selskaper tilbyr kontrollpaneler for sine kunder. Hvis du er en av dem, kan du kanskje finne en seksjon i kontrollpanelet for å administrere dine cron-jobber.
Kjører denne kommandoen vil starte vi (tekstredigerer) og la deg redigere innholdet i crontab:
crontab -e
Så det vil bidra til å være kjent med de grunnleggende vi-kommandoene, da det er ganske annerledes enn noen annen tekstredigerer du kanskje har jobbet med.
Hvis du bare vil se eksisterende crontab uten å redigere den, kan du kjøre denne kommandoen:
crontab-l
For å slette innholdet av crontab:
crontab -r
Du kan skrive alle dine cron-jobber inn i en fil og deretter skyve den inn i crontaben:
crontab cron.txt
Vær forsiktig, fordi dette vil overskrive alle eksisterende cron-jobber med innholdet i disse filene, uten advarsel.
Du kan legge til kommentarer etterfulgt av # -tegnet.
# Denne cron-jobben gjør noe veldig viktig 10 * * * * / usr / bin / php /www/virtual/username/cron.php> / dev / null 2> & 1
Som nevnt tidligere, sendes utgangen fra crons som standard via e-post, med mindre du kaster bort dem eller omdirigerer dem til en fil. MAILTO-innstillingen lar deg sette eller endre hvilken e-postadresse som skal sendes til:
MAILTO = "[email protected]" # Denne cron-jobben gjør noe veldig viktig 10 * * * * / usr / bin / php /www/virtual/username/cron.php> / dev / null 2> & 1
CGI-skript kan kjøres som standard, men PHP-skript er ikke. De må løpe gjennom PHP-parseren. Derfor må vi legge banen til parseren før skriptets bane.
* * * * * / usr / bin / php [sti til php script]
Noen ganger kan det være under et annet sted som: "/ usr / local / bin / php". For å finne ut, kan du prøve å kjøre dette på kommandolinjen:
hvilken php
Hvis du ikke håndterer utdataene fra cron-skriptet, vil den sende dem som e-post til din brukerkonto på serveren.
Hvis du setter "> / dev / null 2> & 1" på slutten av cron-jobb-kommandoen (eller en kommando), vil utskriften bli kassert.
Lukkekonsollen (>) brukes til omdirigering av utgang. "/ dev / null" er som et svart hull for utgang. Alt som går der blir ignorert av systemet.
Denne delen "2> & 1" fører til at STDERR (feil) -utgangen blir omdirigert til STDOUT (normal) utgang. Så det ender også opp i "/ dev / null".
For å lagre cron-utgangen i en fil, bruk lukkekonsollen (>) igjen:
10 * * * * / usr / bin / php /www/virtual/username/cron.php> /var/log/cron.log
Det vil omskrive utdatafilen hver gang. Hvis du vil legge til utgangen på slutten av filen i stedet for en fullstendig omskrivning, bruk dobbelt lukkekonsoll (>>) i stedet:
10 * * * * / usr / bin / php /www/virtual/username/cron.php >> /var/log/cron.log
Normalt må du angi parseren i begynnelsen av kommandoen som vi har gjort. Men det er faktisk en måte å gjøre PHP-skriptene dine kjørbare fra kommandolinjen som et CGI-skript.
Du trenger å legge til banen til parseren som den første linjen i skriptet:
#! / Usr / local / bin / php
Pass også på å sette riktig chmod (som 755) for å gjøre filen kjørbar.
Når du har et kjørbart skript, kan cron-jobben være kortere slik:
10 * * * * /www/virtual/username/hello.php
I noen tilfeller kan du ha hyppige løpende cron-jobber, og du vil kanskje ikke at de skal kollidere hvis de tar lengre tid å løpe enn selve frekvensen.
For eksempel kan du ha en cron-jobb som kjører hvert minutt. Likevel kan det ta lengre tid enn ett minutt å løpe hver gang. Dette kan føre til at en annen forekomst av det samme cron-skriptet begynner å kjøre før den forrige avslutter. Du kan lage for mange opptatt prosesser på denne måten og muligens krasje serveren hvis de fortsetter å senke hverandre, og føre til at flere prosesser blir opprettet over tid ...
Dette problemet kan løses via fillåsing, og nærmere bestemt låser ikke-blokkerende (LOCK_NB) filtypen. (Hvis du ikke er kjent med fillåsing, foreslår jeg at du leser om det først.)
Du kan legge til denne koden i cron jobbscript:
Accentsconagua
$ fp = fopen ('/ tmp / lock.txt', 'r +'); hvis (! flokk ($ fp, LOCK_EX | LOCK_NB)) echo 'Kan ikke skaffe lås'; exit (1); / * ... * / fclose ($ fp); Med vanlige fillås vil flokken () funksjonssamtalen blokkere skriptet hvis det finnes en eksisterende lås. Og det ville frigjøre en gang at låsen er borte. Men med en ikke-blokkerende lås, for eksempel i koden ovenfor, stopper funksjonsanropet ikke skriptet, men returnerer umiddelbart FALSE hvis det finnes en eksisterende lås. Så i dette tilfellet kan vi umiddelbart gå ut av skriptet når vi ser at det finnes en eksisterende lås, noe som indikerer at en annen cron-jobb for tiden kjører.
Når du skriver en cron-jobb i et webspråkspråk som PHP, kan du være sikker på at ingen kan utføre det ved bare å laste det fra nettleseren. Et enkelt alternativ ville være å lagre disse skriptene utenfor webmappen din. Dette kan imidlertid ikke være praktisk eller foretrukket for noen utviklere, hvis de ønsker å beholde sine cron jobbsskript rett innenfor deres webapplikasjonsmapper.
Hvis du setter alle cron-jobbskriptene i en mappe, blokkerer du tilgang ved å sette denne linjen i en .htaccess-fil:
nekte fra alle
Eller du kan også nekte tilgang til skript på individuell basis ved å sette denne linjen i begynnelsen:
hvis (isset ($ _ SERVER ['REMOTE_ADDR'])) dør ('Tillatelse nektet.'); Dette vil sikre at når man får tilgang til skriptet fra nettet, vil det avbryte umiddelbart.
Takk for at du leser. Selv om cron-jobber bare virker som et verktøy bare for systemadministratorer, er de faktisk relevante for mange typer webapplikasjoner.
Vennligst legg inn dine kommentarer og spørsmål, og ha en flott dag!
Visste du at du kan tjene opp til $ 600 for å skrive en PLUS-opplæring og / eller screencast for oss? Vi leter etter dybde og velskrevne opplæringsprogrammer om HTML, CSS, PHP og JavaScript. Hvis du er i stand til å kontakte Jeffrey på [email protected].
Vær oppmerksom på at faktisk kompensasjon vil være avhengig av kvaliteten på den endelige opplæringen og screencast.
