Next Generation Cron With systemd Oprettelse af en timer

Har du brug for at planlægge en opgave i fremtiden på din computer? Dette kan se simpelt ud - når alt kommer til alt er din opvaskemaskine i stand til at vente, før den startes ved hjælp af en knap - men nogle gange laver computere så enkle opgaver så hårdt.Men hvis du har noget baggrund, har du sandsynligvis hørt om cron, dette stykke software fuldt dedikeret til at starte den rigtige opgave på det rigtige tidspunkt. Men dette værktøj er virkelig designet med enkelhed i tankerne, og du kan i sidste ende have dårlige overraskelser.Hvis det nogensinde lykkedes dig at planlægge en opgave på Windows, har du brugt Windows Task Planner. Det har som standard en GUI, men det gør det ikke så nemt at bruge det også: disse to systemer starter bare en proces på et fast tidspunkt og en bestemt dato.

For at forstå, hvordan systemd kan være nyttigt for dig der, tager jeg et eksempel.

Hvilke faldgruber systemtimere undgår dig?

Hvis du nogensinde ejer en maskine med data, som du holder af, skal du have en kopi af dine data et andet, sandsynligvis mere sikkert sted. Hvis du administrerer en server, er det obligatorisk: når alt kommer til alt, hvordan vil du gendanne, hvis din harddisk fejler, og forhindre dig i at gendanne data?

Så som en ansvarlig person opretter du backup hver uge eller hver dag. Du kan konfigurere det ved hjælp af cron, du planlægger det kl. 04:24, men her starter problemet: hvad hvis din server lukker ned fra kl. 04:10 til kl?

Nå, det er sandsynligt, at cron bare springer den sikkerhedskopi over. Dette kan være kritisk, hvis det sker ofte og lydløst, eller hvis din kode er afhængig af, at den kører, og den kan mislykkes på anden måde. Generelt sker dette, når du opretter en oprydningsopgave via cron, og den starter ikke. Pludselig kan din kode muligvis ikke have nok plads til at fortsætte og vil bryde - det er trist, så trist, højre, hr. Elton John.

Men hvis en savnet lancering kan være et problem, forestil dig et sekund - wow, John Lennon nu? - at din opgave går for meget langsomt. Hvis din opgave er indstillet til at køre hvert 10. minut, men det tager 15 minutter at gennemføre, starter cron eller Windows med glæde en anden opgave, selvom den aktuelle opgave ikke er væk endnu - og så har du to forekomster af din opgave, der kører samtidigt , som er perfekt opskrift til katastrofe. Når et program kører samtidigt, mens det ikke er designet til at gøre det, vil det sandsynligvis ødelægge filer, andre software, databaser - og din server bliver pludselig et synkende skib som Titanic.

OK, måske går jeg for langt med Titanic, men du får ideen. Selvom systemd ikke kunne have gjort meget for at redde dette skib, kan det hjælpe dig med alle disse mangler og sikre dig en længere juleferie takket være de fejl, det vil undgå dig. Det er tid nu at lære at indstille systemtimere.

Sådan planlægger du automatisk serverback-up?

Først og fremmest udløser systemd-timere en systemd-tjeneste, så inden du planlægger din opgave, skal du først gøre den til en tjeneste. Heldigvis har jeg skrevet en guide til oprettelse af systemd-service, på denne måde vil det introducere dig med systemds måde at arbejde på. Du bør læse det, inden du går videre. Medmindre du Nemlig ved hvad du laver, din systemd-servicefil skal ikke indeholder enhver WantedBy = indstilling. Hvis du vil starte din tjeneste på et bestemt tidspunkt, vil du sandsynligvis ikke starte den ved opstart.

Takket være systemd-servicesystemet er det umuligt at have flere forekomster af din opgave ved en fejltagelse: hvis en opgave allerede kører, springer den bare over denne start og lader den aktuelt kørende opgave afslutte sit job.

Når du har en systemd-tjeneste at planlægge, skal du oprette en fil med samme filnavn som din tjeneste, bortset fra at den skal ende med .timer i stedet for .service. I vores eksempel på automatisk sikkerhedskopiering ville tjenesten være automatisk sikkerhedskopiering.service og timeren ville være automatisk backup.timer. Begge filer skal være i samme bibliotek. Som jeg fortalte dig i systemd-serviceartiklen, anbefaler jeg, at du skriver disse filer et normalt sted som dit hjemmekatalog og derefter kopierer dem til en systemd-mappe, når du er færdig med dine redigeringer.

Så lad mig vise dig, hvordan vores timer-fil ser ud:

[Enhed]
Beskrivelse = Planlæg sikkerhedskopier i løbet af spidsbelastningstider
[Timer]
OnCalendar = * - * - * 03:00:00
RandomizedDelaySec = 7200
Vedvarende = sandt
[Installere]
WantedBy = timere.mål

Ligesom i systemd-tjenester er der 3 sektioner. [Enhed] eller [Install] fungerer nøjagtigt det samme som forklaret i min artikel om systemtjenester. Bemærk, at WantedBy = er vigtigt her, fordi timere kan startes eller stoppes, så hvis du ikke beder systemd om at starte din timer under opstart, vil den aldrig udløse. timere.mål er et specielt systemmål for timere.

Nu, [Timer] sektionen. Inde i den finder du alle indstillinger relateret til, hvornår timeren skal udløses. Til vores automatiserede sikkerhedskopiering har jeg fortalt systemd at køre den mellem kl. 3 og kl. 5 på serverens tidszone. Det nøjagtige tidspunkt er tilfældigt hver dag.

OnCalendar = indstiller timeren, der er relateret til din servers tid (vægur), f.eks. Hver søndag kl. Hvis du tidligere har brugt cron, skal du være fortrolig med denne syntaks. Det har dog nogle ekstra fordele.

Hvis du f.eks. Vil have, at der skal ske noget hver time, kan du gøre sådan:

OnCalendar = hver time

og dagligt:

OnCalendar = dagligt

Faktisk understøtter det alle følgende værdier:

1. minutvis
2. hver time
3. daglige
4. månedlige
5. ugentlig
6. årligt
7. kvartalsvis
8. Halvårligt

Der er dog et problem med disse nøgleord: for eksempel udløser daglige altid en midnat, hvilket ofte er en spidsbelastningstid i computersystemer. Derfor anbefales det at bruge RandomizedDelaySec = (dets anvendelse er angivet nedenfor). Alligevel er det ikke en god mulighed for sikkerhedskopiering: midnat er ikke ude i spidsbelastningstid, det er snarere det omvendte. Så vi er nødt til at indstille mere nøjagtigt, når vi vil se, at opgaven startes.

Hvis du vil have mere kontrol, kan du skrive en dato som 2018-12-06 12:49:37. Nå, hvis du er så specifik, vil du bare udløse timeren en gang. For at gøre det tilbagevendende erstatter du et af disse elementer med * stjerne.

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

Som du kan se ovenfor, i vores backup-eksempel, er hele datodelen * - * - *, hvilket betyder at den skal forekomme hver dag i hver måned hvert år. Nu hvis du gør:

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

Derefter kører den hver 25. december kl. Perfekt systemtimer til julemanden - selvom jeg tvivler på, at han nogensinde har brug for en! Så asterisk tilføjer gentagelse, hvor du sætter det. Hvis du sætter det i årsmark, betyder det "hvert år" osv.

Endelig kan du tilføje UTC i slutningen af ​​linjen for at bruge UTC-tid i stedet for lokal tidszone. For eksempel nulstiller nogle tjenester deres API-kvoter ved midnat, men for at undgå enhver tidszoneforstyrrelse bruger den UTC. Så for sådanne opgaver ville du gøre:

OnCalendar = daglig UTC

Lad os nu løse et andet problem: myldretiden. systemd har også en indstilling til at kæmpe imod det.

RandomizedDelaySec = gør det muligt at forsinke opgaven tilfældigt. Værdien er det maksimale antal sekunder, som timeren forsinker. Det er specifikt beregnet til sådanne tilfælde. Du husker, at i systemd udløses dagligt altid ved midnat? Nå, ugentlig udløser altid mandag midnat og årlige udløsere ved 1. januar midnat, en af ​​de værste toppe i året med netværksafbrydelser overalt. Du ønsker bestemt ikke, at det skal ske.

Ved at tilføje en forsinkelse fjerner du problemet: det forsinker automatisk din opgave på et ukendt tidspunkt. Tilfældighed her er vigtig, fordi det er langt mere sandsynligt, at det er, selvom det er tilfældigt, og en jævn belastning giver mulighed for bedre at optimere dine opgaver.

Sig, at du skal køre dine opgaver omkring kl. 7 om morgenen, men du vil tillade en lille forsinkelse på maks. 15 minutter, du vil gerne have dette:

RandomizedDelaySec = 900

Det skulle være nok til forsinkelser. Nogle gange er endda millisekunder forsinkelser nok til at forhindre utilsigtede pigge.

Persistent = tager sig af ubesvarede timerudløsere. Hvad hvis din server lukkes om natten? Nå, sikkerhedskopien ville slet ikke udløse. Hvis du sætter det til sandt, tillader systemd at køre det i næste opstart i sådanne tilfælde. På denne måde ved du på en eller anden måde, at timers opgave køres. Dens anvendelse er enkel, du skal bare gøre dette:

Vedvarende = sandt

Dette har dog en ulempe, der alligevel er svært at undgå: når flere opgaver fra forskellige timere går glip af, kører de alle ved opstart og bremser opstarten. Efter min mening er det meget bedre, end hvis det aldrig kører, og trods alt er det normalt, det mest passende tidspunkt at køre timeren er, når det er planlagt, bagefter vil det sandsynligvis være upassende alligevel.

OnBootSec = er den sidste mulighed, jeg viser dig (men ikke mindst). Det er, hvis du vil udløse en timer et stykke tid efter opstart i stedet for baseret på kalender. For eksempel, hvis du har brug for at kontrollere ved opstart, om din server er startet korrekt og fungerer som beregnet, kan du skrive en kontroltjeneste og bruge denne timerindstilling til at udløse den, efter at systemet havde nok tid til at starte.

Lad os sige, at systemet har brug for 3 minutter for at starte, du kunne gøre:

OnBootSec = 180

Og på trods af navnet kan du også gøre:

OnBootSec = 3 minutter

Hvis du præciserer både OnBootSec = og OnCalendar =, starter den tjenesten, når nogen af ​​disse 2 begivenheder sker.

Okay, nu er det tid til at gemme din fil, kopiere den til systemmappen, hvis du fulgte mit råd ovenfor, og test om din timer fungerer korrekt.

Aktivér din nye timer og overvågning

For at teste din nye timer skal du fortælle systemd, at du har tilføjet en ny timer, så du skal skrive denne kommando:

$ sudo systemctl dæmon-genindlæsning

Nu tager systemd hensyn til din nye timer og ser nøje på, hvornår du skal køre din opgave. Da systemd altid kører, er det trods alt en af ​​de bedste kandidater til at styre og køre dine planlagte opgaver.

En ting, du måske synes er modstridende: En timer er som standard deaktiveret. For at aktivere det skal du udføre denne kommando:

$ sudo systemctl aktiver - nu automatisk backup.timer

Du vil sandsynligvis gerne se, om din timer fungerer som forventet. Gode ​​nyheder: systemd er endda venlig nok til at have en kommando, der fortæller dig, hvornår den sidst blev lanceret, og hvornår den næste lancering er planlagt (undtagen hvis timeren er indstillet til kun at køre ved opstart, da systemd ikke ved, hvornår systemet starter igen, selvfølgelig). Her er den kommando:

$ systemctl status automatiseret backup.timer

Endelig, når du ikke længere har brug for timeren, kan du også deaktivere den:

$ sudo systemctl deaktiver - nu automatisk backup.timer

Konklusion

Ved hjælp af systemd-timere er din styring af planlagte opgaver til et næste niveau: ærligt, jeg føler personligt, at planlagte opgaver burde have været sådan siden år.

Åh, en lille overraskelse for dig: alle systemd-timere er logget i et godt struktureret system med filtrering, logrotation og lignende. Så jeg inviterer dig til at se, hvordan du kan se logfiler om dine planlagte opgaver!