Next Generation Cron With systemd Opprette en tidtaker

Trenger du å planlegge noen oppgaver i fremtiden på datamaskinen din? Dette kan se enkelt ut - når alt kommer til alt kan oppvaskmaskinen din vente før du starter den ved hjelp av en knapp - men noen ganger gjør datamaskiner så enkle oppgaver så hardt.Men hvis du har litt bakgrunn, har du sannsynligvis hørt om cron, denne programvaren er dedikert til å starte riktig oppgave til rett tid. Men dette verktøyet er virkelig designet med tanke på enkelhet, og du kan til slutt få dårlige overraskelser.Hvis du noen gang lyktes med å planlegge en oppgave på Windows, har du brukt Windows Task Planner. Det har en GUI som standard, men det gjør det ikke så enkelt å bruke det også: disse to systemene starter bare en prosess på et fast tidspunkt og dato.

For å forstå hvordan systemd kan være nyttig for deg der, tar jeg et eksempel.

Hvilke fallgruver systemtidsurene vil unngå deg?

Hvis du noen gang eier en maskin med data du bryr deg om, vil du ha en kopi av dataene dine på et annet, sannsynligvis tryggere sted. Hvis du administrerer en server, er det obligatorisk: når alt kommer til alt, hvordan vil du gjenopprette hvis harddisken mislykkes og forhindre at du gjenoppretter data?

Så som en ansvarlig person setter du opp sikkerhetskopiering hver uke eller hver dag. Du kan konfigurere det ved hjelp av cron, du planlegger det klokken 04:24, men her starter problemet: hva om serveren din blir slått av fra kl. 04:10 til 04:30 av en eller annen grunn?

Vel, det er sannsynlig at cron bare hopper over den sikkerhetskopien. Dette kan være kritisk hvis det skjer ofte og lydløst, eller hvis koden din er avhengig av at den kjører, og den kan mislykkes på annen måte. Vanligvis skjer dette når du setter opp en oppryddingsoppgave via cron og den ikke starter. Plutselig kan det hende at koden din ikke har nok plass til å fortsette og vil bryte - det er trist, så trist situasjon, ikke sant Elton John.

Imidlertid, hvis en savnet lansering kan være et problem, forestill deg et sekund - wow, John Lennon nå? - at oppgaven din går for mye sakte. Hvis oppgaven din er satt til å kjøre hvert 10. minutt, men tar 15 minutter å fullføre, vil cron eller Windows med glede starte en annen oppgave selv om den gjeldende oppgaven ikke er borte ennå - og så vil du ha to forekomster av at oppgaven din kjører samtidig , hvilken er den perfekt oppskrift til katastrofe. Når et program kjører samtidig mens det ikke er designet for å gjøre det, vil det sannsynligvis ødelegge filer, andre programvare, databaser - og serveren din blir plutselig et synkende skip som Titanic.

OK, kanskje jeg går for langt med Titanic, men du skjønner. Selv om systemd ikke kunne ha gjort mye for å redde dette skipet, kan det hjelpe deg med alle disse manglene og sikre deg en lengre juleferie takket være feilene det vil unngå deg. Det er på tide å bli kjent med hvordan du setter opp systemtimere.

Hvordan planlegge automatisk sikkerhetskopiering av serveren?

Først og fremst utløser systemd-tidtakere en systemtjeneste, så før du planlegger oppgaven din, må du først gjøre den til en tjeneste. Heldigvis har jeg skrevet en guide for å opprette systemd-tjeneste, på denne måten vil den introdusere deg for systemds måte å jobbe på. Du bør lese den før du går videre. Med mindre du nøyaktig vet hva du gjør, din systemd-tjenestefil burde ikke inneholder noen WantedBy = innstillinger. Hvis du vil starte tjenesten til et bestemt tidspunkt, vil du sannsynligvis ikke starte den ved oppstart.

Takket være systemd-servicesystemet er det umulig å ha flere forekomster av oppgaven din ved en feiltakelse: Hvis en oppgave allerede kjører, hopper den bare over lanseringen og lar den nåværende oppgaven fullføre jobben sin.

Når du har en systemd-tjeneste å planlegge, oppretter du en fil med samme filnavn som tjenesten din, bortsett fra at den skal ende med .timer i stedet for .service. I vårt eksempel på automatisk sikkerhetskopiering vil tjenesten være automatisk sikkerhetskopiering.tjenesten og tidtakeren vil være automatisk sikkerhetskopiering.timer. Begge filene skal være i samme katalog. Som jeg fortalte deg i systemd-tjenesteartikkelen, anbefaler jeg deg å skrive disse filene på et normalt sted, for eksempel i hjemmekatalogen, og deretter kopiere dem til en systemd-mappe når du er ferdig med endringene.

Så la meg vise deg hvordan tidtakerfilen vår ser ut:

[Enhet]
Beskrivelse = Planlegg sikkerhetskopier i løpet av topptimer
[Timer]
OnCalendar = * - * - * 03:00:00
RandomizedDelaySec = 7200
Vedvarende = sant
[Installere]
WantedBy = tidtakere.mål

I likhet med i systemtjenester er det 3 seksjoner. [Unit] eller [Install] fungerer nøyaktig det samme som forklart i artikkelen om systemtjenester. Vær oppmerksom på at WantedBy = er viktig her fordi timere kan startes eller stoppes, så hvis du ikke ber systemd om å starte timeren under oppstart, vil den aldri utløse. tidtakere.mål er et spesielt systemmål for tidtakere.

Nå, [Timer] -delen. Inne i den finner du alle innstillinger relatert til når tidtakeren skal utløses. For vår automatiserte sikkerhetskopiering har jeg fortalt systemd å kjøre den mellom klokken 03.00 og 05.00 på serverens tidssone. Den nøyaktige tiden er tilfeldig hver dag.

OnCalendar = stiller inn timeren relatert til serverens tid (veggklokke), for eksempel hver søndag klokka 13.00. Hvis du har brukt cron tidligere, bør du være veldig kjent med denne syntaksen. Imidlertid har det noen ekstra fordeler.

Hvis du for eksempel vil at noe skal skje hver time, kan du gjøre slik:

OnCalendar = time

og daglig:

OnCalendar = daglig

Faktisk støtter den alle følgende verdier:

minutiøst
hver time
daglig
månedlig
ukentlig
årlig
kvartalsvis
halvårlig

Det er imidlertid et problem med disse nøkkelordene: For eksempel utløser daglig alltid en midnatt, som ofte er en topptid i databehandlingssystemer. Derfor anbefales det å bruke RandomizedDelaySec = (bruken er spesifisert nedenfor). Uansett for sikkerhetskopiering er det ikke et godt alternativ: midnatt er ikke utenfor peak timer, det er heller det motsatte. Så vi må sette mer nøyaktig når vi vil se at oppgaven startes.

Hvis du vil ha mer kontroll, kan du skrive en dato som 2018-12-06 12:49:37. Vel, hvis du er så spesifikk, vil du bare utløse timeren en gang. For å gjøre det tilbakevendende, erstatter du noen av disse elementene med * stjerne.

OnCalendar = * - * - * 03:00:00

Som du kan se ovenfor, i vårt backup-eksempel, er hele datodelen * - * - *, noe som betyr at den skal forekomme hver dag i hver måned i hvert år. Nå hvis du gjør det:

OnCalendar = * - 12-25 03:00:00

Deretter går den hver 25. desember klokken 03.00. Perfekt systemtidsur for julenissen - selv om jeg tviler på at han noen gang vil trenge en! Så stjerne legger til gjentakelse der du legger den. Hvis du setter det i årsfelt, betyr det "hvert år" osv.

Til slutt kan du legge til UTC på slutten av linjen for å bruke UTC-tid i stedet for lokal tidssone. For eksempel tilbakestiller noen tjenester API-kvotene sine ved midnatt, men for å unngå tidssone-bias bruker den UTC. Så for slike oppgaver, vil du gjøre:

OnCalendar = daglig UTC

La oss nå løse et annet problem: rushtiden. systemd har også en innstilling for å kjempe mot det.

RandomizedDelaySec = lar forsinke oppgaven tilfeldig tid. Verdien er det maksimale antall sekunder timeren vil forsinke. Det er spesielt ment for slike tilfeller. Du husker at i systemd utløses daglig alltid ved midnatt? Vel, utløser alltid ukentlig mandag midnatt, og årlige utløsere 1. januar midnatt, en av de verste toppene i året med nettverksbrudd overalt. Du vil absolutt ikke at det skal skje.

Ved å legge til en forsinkelse fjerner du problemet: det vil automatisk forsinke oppgaven på et ukjent tidspunkt. Tilfeldighet her er viktig fordi det er langt mer sannsynlig å være selv når det er tilfeldig og en jevn belastning gjør det mulig å bedre optimalisere oppgavene dine.

Si at du må kjøre oppgavene dine rundt klokka 7 om morgenen, men at du vil tillate en liten forsinkelse på maks 15 minutter, du vil gjøre dette:

RandomizedDelaySec = 900

Det burde være nok for forsinkelser. Noen ganger er til og med millisekunder forsinkelser nok til å forhindre utilsiktede pigger.

Persistent = tar seg av glipp av tidtakerutløsere. Hva om serveren din blir stengt om natten? Vel, sikkerhetskopien ville aldri utløst i det hele tatt. Hvis du setter det til sant, kan systemet kjøre det på neste oppstart i slike tilfeller. På denne måten vet du på en eller annen måte, timeren vil bli kjørt. Bruken av den er enkel, du gjør bare dette:

Vedvarende = sant

Dette har imidlertid en ulempe som det er veldig vanskelig å unngå uansett: når flere oppgaver fra forskjellige tidtakere blir savnet, vil de alle kjøre ved oppstart og redusere oppstarten. Etter min mening er det mye bedre enn om det aldri går, og når alt kommer til alt, er det mest hensiktsmessige øyeblikket å kjøre timeren når den er planlagt, etterpå vil det sannsynligvis være upassende uansett.

OnBootSec = er det siste alternativet jeg vil vise deg (men ikke minst). Det er hvis du vil utløse en tidtaker en stund etter oppstart i stedet for basert på kalender. Hvis du for eksempel må sjekke ved oppstart om serveren din startes riktig og fungerer som forutsatt, kan du skrive en sjekketjeneste og bruke den tidsinnstillingen for å utløse den etter at systemet hadde nok tid til å starte opp.

La oss si at systemet trenger 3 minutter for å starte opp, du kan gjøre:

OnBootSec = 180

Og til tross for navnet kan du også gjøre:

OnBootSec = 3 minutter

Hvis du presiserer både OnBootSec = og OnCalendar =, vil den starte tjenesten når noen av disse 2 hendelsene skjer.

OK, nå er det på tide å lagre filen, kopiere den til systemmappen hvis du fulgte rådene mine ovenfor, og teste om tidtakeren din fungerer som den skal.

Aktiver den nye tidtakeren og overvåking

For å teste den nye tidtakeren, må du fortelle systemd at du har lagt til en ny tidtaker, så du må skrive denne kommandoen:

$ sudo systemctl daemon-reload

Nå vil systemd ta hensyn til den nye tidtakeren og se nøye på når du skal kjøre oppgaven. Ettersom systemd alltid kjører, er det tross alt en av de beste kandidatene for å administrere og kjøre dine planlagte oppgaver.

En ting du kanskje synes er motstridende: en tidtaker er som standard deaktivert. For å aktivere det, må du gjøre denne kommandoen:

$ sudo systemctl aktiver - nå automatisk sikkerhetskopiering.timer

Du vil da sannsynligvis ønske å se om tidtakeren din fungerer som forventet. Gode nyheter: systemd er til og med snill nok til å ha en kommando som forteller deg når den sist ble lansert og når neste lansering er planlagt (bortsett fra hvis timeren er satt til å kjøre bare ved oppstart, da systemd ikke vet når systemet vil starte opp igjen, tydeligvis). Her er den kommandoen:

$ systemctl-status automatisk sikkerhetskopiering.timer

Til slutt, når du ikke lenger trenger tidtakeren, kan du også deaktivere den:

$ sudo systemctl deaktivere - nå automatisk sikkerhetskopiering.timer

Konklusjon

Ved å bruke systemtimere er administrasjonen av planlagte oppgaver til et neste nivå: ærlig talt føler jeg personlig at planlagte oppgaver burde ha vært slik siden år.

Å, en liten overraskelse for deg: alle systemtimere er logget inn i et godt strukturert system med filtrering, loggrotasjon og lignende. Så jeg inviterer deg til å se hvordan du kan se logger om dine planlagte oppgaver!