Phenquestions
Med sine tjenester gjør systemd alt dette enklere, veldig enklere. Så snart du vil ha noe som overvåker applikasjonen din og enkel kontroll over den, er systemd veien å gå, og det er det jeg skal forklare her!
Hvor er Systemd Services
For å legge til en ny tjeneste, vel, må du svare på dette spørsmålet. Som alltid i systemd, avhenger det om tjenesten bare er for brukeren din eller hele systemet. Vi vil fokusere på hvordan systemd fungerer for hele systemtjenester.
Den nøyaktige plasseringen avhenger av hvorfor og hvordan tjenesten ble installert. Hvis tjenesten installeres av en pakkebehandling, vil den vanligvis være i / usr / lib / systemd / system. For programvare du utvikler eller de som ikke støtter systemd av seg selv, vil du legge tjenestefilen i / usr / local / lib / systemd / system. Vær imidlertid oppmerksom på at noen distribusjoner ikke støtter denne mappen i / usr / local. Til slutt, hvis du vil konfigurere en eksisterende systemd-tjeneste, er / etc / systemd / system veien å gå.
Inne i disse mappene kan du finne flere filtyper som *.stikkontakt, *.mål eller *.service. Åpenbart skal vi fokusere på det siste. systemd bruker filnavnet som navnet på tjenesten når du starter den eller stopper den osv. Så generelt inneholder filnavn i bruk bare alfanumeriske tegn sammen med bindestreker og understrekninger. Under utviklingen anbefaler jeg å lage den i dokumentene dine og deretter kopiere den til systemets beliggenhet når du er ferdig, det vil unngå problemer hvis du sparer midt i redigeringen.
OK, så opprett servicefilen i dokumentene. Nå er vi klare til å gjennomgå hvordan vi skriver denne filen.
[Merk: Se potensiell feilrapport i kommentarseksjonen i dette blogginnlegget]
Beskrivelse = Penguins Web Application HTTP-server (kjører i port 8080)
WantedBy = flerbruker.mål
[Service]
Type = enkel
ExecStart = / usr / bin / python3 / usr / local / bin / penguin-web-app / main.py
Start på nytt = alltid
Filformatet er faktisk nær ini. Jeg vet at det kan være rart da ini-filer ofte finnes i Windows, men det er slik det fungerer. Servicefilen er først delt inn i to seksjoner: [Enhet] og [Service]. Hver seksjon konfigurerer et bestemt aspekt av systemd: [Unit] inneholder elementer som deles av alle systemd unit-filer mens [Service] bare er for konfigurasjonsspesifikke for å sette opp en ny tjeneste.
Deretter er seksjonen konfigurert med egenskaper som Description = eller ExecStart =. Verdien er skilt fra eiendomsnavnet med likhetstegnet = uten mellomrom.
La oss gå tilbake til filen vist ovenfor. Den beskriver en tjeneste designet for å kjøre en webapp skrevet i Python om pingviner. systemd vil starte den på nytt når prosessen avsluttes og starter serveren ved oppstart av serveren hvis du aktiverer den med systemctl aktiver kommando. Kult eh?
Men du er kanskje din neste webapp ikke handler om pingviner - og det er synd - og det er ikke skrevet i Python. I dette tilfellet vil du lære mer om mulige konfigurasjoner.
Egenskaper til Systemd Services
La oss først fokusere på egenskapene i [Unit]:
Beskrivelse = handler bare om å gi en klar beskrivelse av hva tjenesten gjør. Den vises i tjenestelisten, tjenesteloggene, slik at du vil at den skal være beskrivende, men den skal være i en linje og en setning.
WantedBy = tillater å si til systemd: når denne tingen er startet, starter meg også. Vanligvis vil du sette navnet på et mål. Eksempler på vanlige mål:
- flerbruker.mål: når serveren er OK og er klar til å kjøre kommandolinjeprogrammer
- grafisk.mål: når GNOME eller KDE er klar
- nettverksoppkobling.mål: når serveren er koblet riktig til et nettverk
OK for begynnelsen er disse egenskapene til [Enhet] nok. La oss ta en titt på [Service] nå.
Type = hjelper systemd til å vite om en tjeneste kjører. Her er vanlige typer:
- enkel er sannsynligvis den mest brukte: systemd anser prosessen du starter som den som gjør tjenesten. Hvis prosessen stopper, vurderer den tjenesten også stoppet osv.
- Forking foretrekkes for applikasjoner som ble skrevet for å være en server, men uten hjelp fra et tjenestestyringssystem. I utgangspunktet forventer den at den lanserte prosessen vil gaffel og at gaffelen betraktes som den endelige prosessen for tjenesten. For å være mer nøyaktig, kan du også hjelpe systemd med en PID-fil, der PID-en for prosessen som skal spores er skrevet av den lanserte applikasjonen.
ExecStart = er sannsynligvis det viktigste for en tjeneste: den forutsetter hvilket program du skal starte når du starter tjenesten. Som du kan se i Penguin-tjenesten, har jeg brukt / usr / bin / python3 og ikke python3 med en gang. Det er fordi systemdokumentasjon eksplisitt anbefaler å bruke absolutte baner for å unngå overraskelser.
Men det er også av en annen grunn. Andre tjenesters styringssystem har en tendens til å være basert på Shell-skript. Systemd kjører imidlertid ikke et skall som standard. Så du kan ikke gi direkte en shell-kommando i ExecStart =. Du kan imidlertid fortsatt bruke et skallskript ved å gjøre:
ExecStart = / usr / bin / bash / usr / local / bin / launch-penguin-server.shIkke så vanskelig ikke sant? Merk at hvis du trenger å kjøre en prosess for å signalisere at tjenesten din skal stoppe rent, eksisterer ExecStop =, så vel som ExecReload = for omlasting av tjenester.
Restart = lar deg eksplisitt fortelle når tjenesten skal startes på nytt. Dette er en av de viktigste funksjonene i systemd: det sørger for at tjenesten din holder seg opp så lenge du vil, så vær nøye med dette alternativet.
| Start på nytt = | Betydning |
| alltid | systemd vil fortsette å starte den når den avsluttes eller krasjer. Vel, til du stopper systemctl-navnet på tjenesten.service. Det er perfekt for servere og online-tjenester, ettersom du foretrekker få ubrukelige omstarter enn å måtte starte tjenesten manuelt uten grunn. |
| på-unormal | Start tjenesten på nytt når tjenesteprosessen krasjer. Imidlertid, hvis programmet avsluttes rent, ikke start det på nytt. Det er mer nyttig for cron-jobber som tjenester som trenger å gjøre en oppgave pålitelig, men som ikke trenger å løpe hele tiden. |
| på feil | I likhet med unormal, men den starter også tjenesten på nytt når applikasjonen avsluttes rent, men med en utgangskode som ikke er null. Utgangskoder som ikke er null betyr vanligvis at det oppstod en feil. |
| Nei | systemd vil ikke starte tjenesten på nytt automatisk. Vanligvis nyttig for å få tilgang til andre systemfunksjoner som logging uten omstartsfunksjonen. |
WorkingDirectory = kan håndheve en arbeidskatalog når du starter applikasjonen. Verdien må være en absolutt katalogbane. Arbeidskatalog brukes når du bruker relative stier i programmets kode. For vår pingvintjeneste kan det være:
WorkingDirectory = / srv / penguin-web-app /Da er sikkerhet viktig, så du vil vanligvis ikke starte tjenesten din med root-privilegier. Bruker = og Gruppe = lar deg angi bruker- eller gruppenavn eller UID / GID som applikasjonen din vil bli lansert under. For eksempel:
Bruker = pingvin-nettGruppe = pingvin-nett
EnvironmentFile = er et kraftig alternativ. Programmer som kjører som tjenester, trenger ofte konfigurasjon, og miljøfiler tillater å angi konfigurasjonen på to måter:
- Søknaden kan lese miljøvariabelen direkte.
- Men du kan også angi forskjellige kommandolinjeargumenter for applikasjonen din uten å endre tjenestefilen.
Syntaksen til denne filen er enkel: du skriver inn navnet på miljøvariabelen, likhetstegnet = og deretter verdien. Deretter setter du den absolutte banen til miljøfilen din til EnvironmentFile-egenskapen.
Så eksempel:
EnvironmentFile = / etc / penguin-web-app / environmentOg / etc / penguin-web-app / miljø-filen inneholder:
LISTEN_PORT = 8080Da vil pingvinene våre få tilgang til miljøvariabelen LISTEN_PORT og lytte til den forventede porten.
Lagre og start den nyopprettede Systemd-tjenesten
Så hvis du fulgte rådene mine, redigerte du tjenestefilen din i hjemmekatalogen. Når du er fornøyd, kopier du filen til / usr / local / lib / systemd / system, forutsatt at distribusjonen din støtter den banen. Filnavnet til tjenestefilen din vil være tjenestenavnet. Dette filnavnet må ende med .service. For eksempel, for vår pingvinserver, ville det være penguin-web-app.service.
Deretter må du fortelle systemd at du har lagt til en ny tjeneste, så du må skrive denne kommandoen:
$ sudo systemctl daemon-reloadOk, nå er systemd klar over den nye tjenesten din, forutsatt at filen din ikke inneholder en syntaksfeil. Tross alt er det din første fil, så det er sannsynlig at du vil gjøre feil. Du må kjøre denne kommandoen ovenfor på hver oppdatering i tjenestefilen din.
Nå er det på tide å starte tjenesten:
$ sudo systemctl start penguin-web-app.serviceHvis det mislykkes med en enhet som ikke er funnet feil som denne:
$ sudo systemctl start penguin-web-app.serviceKunne ikke starte penguin-web-app.service: Enhet ikke funnet.
Det betyr at distribusjonen din ikke støtter katalogen, eller at du ikke navngir tjenestefilen din riktig. Husk å sjekke ut.
Hvis du konfigurerer tjenesten din med WantedBy = og vil at tjenesten din starter automatisk, må du aktivere den med denne kommandoen:
$ sudo systemctl aktivere penguin-web-app.serviceDet kule med en tjeneste er at den kjører i bakgrunnen. Problemet: hvordan du vet om den kjører riktig og om den kjører hvis den kjører i bakgrunnen? Ikke bekymre deg, systemd team tenkte på det også og ga en kommando for å se om det kjører riktig, siden hvor mye tid osv.:
$ systemctl status penguin-web-app.serviceKonklusjon
Gratulerer! Du kan nå få programmene dine til å administreres uten at du bryr deg om å starte den på nytt hver gang. Nå anbefaler jeg deg å lese den andre artikkelen vår om systemd-logger: Master journalctl: forstå systemd-logger. Med det kan du bruke det kraftige loggesystemet på den nye tjenesten din og bygge mer pålitelige servere!
