Systemd Timer

Systemd Timer
I Linux -operativsystemet er SystemD en servicesjef og en systemleder. Det fungerer som et init -system når den kjøres som en første prosess i oppstart. Det holder og holder oversikt over brukerområdetjenestene. For å starte tjenestene til innloggede brukere, starter det med separate forekomster. Tidtakere er enhetsfiler av SystemD som har en utvidelse av “.Timer ”. Disse filene kontrollerer “.service ”-filer eller hendelser i et system.

Det meste av tiden brukes tidtakere som erstatning for cron. Det gir oss innebygd støtte for kalendertidshendelser. Fordelen med tidtakere over cronjobs er at de gir finere-kornet kontroller av hendelser. Disse brukes når en oppgave krever planlegging av et Linux -operativsystem. Hvis vi for eksempel vil starte en prosess når maskinstøvlene våre, bruker vi tidtakerne til det formålet. Tidligere var Cron verktøyet for å gjøre denne typen jobber. Men i dag blir tidtakere brukt til disse formålene.

Tidtakere er nesten som Cron på en måte som de begge gir en tilnærming og mekanisme for planlegging av oppgaver i Linux OS. Cron har sine ulemper, og det er grunnen til at tidtakere erstatter den. For eksempel, hvis vi ønsker å planlegge sikkerhetskopien vår klokka 5 om kvelden og på en eller annen måte, stenger systemet vårt mellom 4:50 og 5:10, hopper Cron hopper over sikkerhetskopien i så fall som dreper formålet med å planlegge.

For å jobbe med tidtakere trenger vi følgende ting som forutsetninger:

  • Rotrettigheter
  • Terminal

SystemD -tiders funksjoner trenger to konfigurasjonsfiler som er:

Timerenhet: Timerenheten holder oversikt over når du skal bruke tjenestefilene. De bruker en forlengelse av “.Timer ”.

Serviceenhet: Dette er enhetskonfigurasjonsfiler. De administrerer og definerer systemprosessene. De har ".Service ”utvidelse som tidligere diskutert.

Nå diskuterer vi hvordan vi kan planlegge en automatisert serverbackup. En annen fordel med SystemD -tjenesten er at den ikke lar oppgavene dine ha flere forekomster. Hvis vi på en eller annen måte starter en oppgave igjen mens den allerede er startet, hopper den over lanseringsstammen og holder den til den nåværende løpsoppgaven har fullført jobben. Etter at vi konfigurerer SystemD -tjenesten vår og kom til å planlegge, oppretter vi en fil med samme navn som vår tjeneste.

Den eneste forskjellen er at den har en forlengelse av “.Timer ”og ikke av service. For eksempel har vi en tjeneste som heter “XYZ”. I så fall har vi “XYZ.Service ”som vårt tjenestenavn og“ XYZ.Timer ”som vår tids navn. En annen ting å huske på er at begge disse filene må være i samme katalog.

Trinn for å lage en systemdimer

Lag et testskript
Dette er et grunnleggende bashskript som et eksempel:

linux@linux-virtualbox: ~ $ nano test.sh

Det forrige skriptet skriver ut datoen.

Lag en tjenestefil
Nå oppretter vi en tjenestefil eller en enhet for å kjøre bashskriptet.

linux@linux-virtualbox: ~ $ nano/etc/systemd/system/ny.service

Dette er et eksempel for å lage tjenestefilen. Den har to alternativer: den ene er "enhet" og den andre er "service". I dette trinnet forteller vi først systemets navn og hva denne enheten gjør. Deretter definerer vi en tjeneste med typen "enkel". Til slutt definerer vi at tjenesten starter i tilfelle feil.

Lag en tidtakerfil
Etter å ha opprettet tjenestefilen, oppretter vi nå en tidtakerfil. Vi kjører følgende kommando for å opprette en timerfil:

linux@linux-virtualbox: ~ $ nano/etc/systemd/system/test.Timer

Den har tre alternativer: “Enhet”, “Timer” og “Installer”. Igjen, etter å ha kjørt kommandoen, definerer vi hva enheten vår gjør. Den har et "timer" -alternativ. Ved hjelp av dette forteller vi systemet når skriptet vårt kjører. Det siste alternativet, "Installer", indikerer når tjenesten vår starter i henhold til løpsnivået. Dette alternativet er bare aktivert når en tjeneste er aktivert ved hjelp av SystemCTL.

La oss nå diskutere alternativene mer dybde for å få et bedre grep om tidtakerne.

Enhet: Dette spesifiserer enheten som vi vil slå på når tidtakeren går tom. Den beståtte parameteren er navnet på en enhet hvis utvidelse ikke må være ".Timer ”. Hvis vi ikke klarer å gjøre det eller ikke ønsker å passere enhetsnavnet, er standardverdien tjenesten som har samme navn som navnet på ".Timer ”i så fall. Som allerede diskutert, er den beste tilnærmingen at vi skal beholde navnet på tjenesten og navnet på tidtakeren det samme.

Timer: Timeralternativet bærer all informasjon om tidtakeren som er definert. I tidsalternativet finner vi alle innstillingene som vi trenger for å utløse tidtakeren. Timerseksjonene har mange alternativer som:

OnActiveEc =, onbootsec =, onStartUpSec =, onUnitActiveEc =, OnUnitInActiveSec =

I timerseksjonen forteller vi også systemet når vi skal kjøre prosessen og når vi skal avslutte prosessen i henhold til serverens tidssone.

Timerseksjonen har også et veldig nyttig og viktig alternativ som er:

Oncalender = sett

Dette alternativet definerer hvor ofte en oppgave utføres. Hvis vi for eksempel vil planlegge en oppgave daglig, bruker vi dette alternativet som "Oncalendar = daglig". Dette utfører oppgaven daglig.

Hvis du vil være mer spesifikk, kan du også bestå en spesifikk datetime i henhold til dine krav. En annen ting å huske på mens du jobber med tidtakere er at de daglige triggerne alltid er ved midnatt, noe som er en topptid i datasystemer. Så for å unngå problemene i løpet av det, anbefaler vi deg å bruke "randomizedelaysec =". Det forsinker timeplanen tilfeldig med en forskjell på noen få sekunder. Det krever en verdi som representerer sekundene som tidtakeren kan bli forsinket.

Problemet er at daglig alltid utløses kl. 12. Uken utløses alltid på mandag midnatt. Og årlig utløses alltid den første januar. Alle disse er topptider, og det er et nettverksbrudd i løpet av disse overalt.

Aktiver og start tidtakeren
Dette er det siste trinnet i oppgaven vår. Vi utfører dette trinnet systematisk. For å utføre denne aktiviteten, må vi gjøre en "Daemon-Reload". For å se om en ny fil opprettes eller en gammel fil blir oppdatert, lastes hele systemet på nytt.

Feilsøking
Noen ganger klarer vi ikke å ta alle problemene på forhånd. I SystemD -tidtakeren kan vi sørge for å fange dem ved å bekrefte "SystemD" -tidenhetene før de aktiverer dem. For å gjøre det, bruker vi kommandoen “SystemD-Analyze-Verify”. Denne kommandoen hjelper oss å finne ut et potensielt problem og fikse det deretter.
Det er også andre kommandoer som hjelper oss med feilsøking og diagnostisering av tidtakerne våre. For eksempel er det en kommando som hjelper oss å bekrefte om tjenesten vår utføres vellykket eller ikke. Kommandoen er som følger:

linux@linux -virtualbox: ~ $ sudo journalctl -s i dag -f -u test.service

Denne kommandoen viser oss når tjenesten sist startet og resultatet av vår bash -kommando som vist i følgende utdrag:

Konklusjon

Vi studerte systemtimeren. Etter å ha fått en detaljert gjennomgang av hva en systemtimer er og den fungerer, implementerte vi et eksempel for å forklare ideen for deg mer kort der vi forklarte hvert trinn i flere deler.