Systemd Unit File Opprette en tjeneste
Med sine tjenester gjør SystemD alt dette enklere, virkelig 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 -tjenester
For å legge til en ny tjeneste, vel, du må 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 er installert av en pakkebehandler, vil den generelt 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 inn/usr/local/lib/SystemD/System. Husk imidlertid at noen distribusjoner ikke støtter denne mappen i /usr /lokal. Til slutt, hvis du vil konfigurere en eksisterende SystemD -tjeneste, er/etc/SystemD/System.
Inne i disse mappene kan du finne flere filutvidelser som *.stikkontakt, *.mål eller *.service. Det er klart vi kommer til å fokusere på det siste. SystemD bruker filnavnet som navnet på tjenesten når du starter det eller stopper det osv. Så generelt inneholder filnavn i tjeneste bare alfanumeriske tegn sammen med bindestrek og understreker. Under utviklingen anbefaler jeg å lage det i dokumentene dine og deretter kopiere det til SystemD -stedet når du er ferdig, vil det unngå deg problemer hvis du sparer midt i redigering.
Ok, så vennligst oppsett tjenestefilen din i dokumentene dine. Nå er vi klare til å gjennomgå hvordan du skriver denne filen.
[Merk: Se potensiell feilrapport i kommentarfeltet i dette blogginnlegget]
Beskrivelse = Penguins Web Application HTTP Server (kjører i port 8080)
WantedBy = Multi-User.mål
[Service]
Type = enkel
ExecStart =/usr/bin/python3/usr/local/bin/penguin-web-app/main.py
Start på nytt = alltid
Filformatet er faktisk i nærheten av INI. Jeg vet at det kan være rart gitt ini -filer finnes ofte i vinduer, men det er slik det fungerer. Tjenestefilen blir først delt i 2 seksjoner: [enhet] og [service]. Hver seksjon konfigurerer et spesifikt aspekt av SystemD: [Enhet] inneholder elementer som deles av alle SystemD -enhetsfiler, mens [Service] bare er for konfigurasjon som er spesifikk for å sette opp en ny tjeneste.
Deretter er delen konfigurert med egenskaper som beskrivelse = eller execStart =. Verdien er atskilt fra eiendomsnavnet med like tegn = uten noen plass.
La oss gå tilbake til filen som er vist ovenfor. Den beskriver en tjeneste designet for å kjøre en webapp skrevet i Python om Penguins. SystemD vil starte den på nytt når prosessen kommer ut og starter serveren etter serverens oppstart hvis du aktiverer den med SystemCTL Enable Command. Kult eh?
Men du er kanskje din neste webapp ikke 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 for SystemD -tjenester
La oss først fokusere på egenskapene i [Enhet]:
Beskrivelse = handler bare om å gi en klar beskrivelse av hvilken tjeneste som gjør. Den vises i tjenestelisten, servicelogger slik at du vil at den skal være beskrivende, men den skal holde seg i en linje og en setning.
WantedBy = tillater å si til Systemd: Når denne tingen startes, starter jeg også. Generelt 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 kommandolinjeapplikasjoner
- grafisk.Mål: Når Gnome eller KDE er klar
- nettverk.Mål: Når serveren er riktig koblet til et nettverk
Ok for begynnelsen er disse egenskapene til [enheten] nok. La oss ta en titt på [service] nå.
Type = hjelper systemd i hvordan du vet om en tjeneste kjører. Her er vanlige typer:
- Enkelt er sannsynligvis den mest brukte: SystemD vurderer prosessen du lanserer som den som gjør tjenesten. Hvis prosessen stopper, vurderer den også tjenesten stoppet osv.
- Gaffel er å foretrekke for applikasjoner som ble skrevet til å være en server, men uten hjelp av et tjenestestyringssystem. I utgangspunktet forventer den at den lanserte prosessen til gaffelen, og at gaffelen regnes som den endelige prosessen for tjenesten. For å være mer nøyaktig, kan du også hjelpe SystemD med en PID -fil, der PID -en i prosessen til sporet er skrevet av den lanserte applikasjonen.
ExecStart = er sannsynligvis det viktigste for en tjeneste: den presenterer hvilken applikasjon 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 SystemD -dokumentasjon eksplisitt anbefaler å bruke absolutte stier for å unngå overraskelser.
Men det er også av en annen grunn. Andre tjenesters styringssystem har en tendens til å være basert på skallskript. SystemD kjører imidlertid ikke et skall som standard som standard. Så du kan ikke gi direkte en skallkommando i execStart =. Du kan imidlertid fortsatt bruke et skallskript ved å gjøre:
ExecStart =/usr/bin/bash/usr/local/bin/lansering-pingvin-server.sh
Ikke så hardt riktig? Merk at hvis du trenger å kjøre en prosess for å signalisere tjenesten din for å stoppe rent, eksisterer execStop =, samt execReload = for omlastingstjenester.
Restart = lar deg eksplisitt fortelle når tjenesten skal startes på nytt. Dette er en av de viktige funksjonene i SystemD: det sikrer at tjenesten din holder seg så lenge du ønsker det, så vær nøye med dette alternativet.
| Omstart = | Betydning |
| alltid | SystemD vil fortsette å starte den på nytt når det avsluttes eller krasjer. Vel, til du gjør SystemCTL Stop Service-Name.service. Det er perfekt for servere og online tjenester, da du foretrekker få ubrukelige omstarter fremfor å måtte starte tjenesten manuelt på nytt uten noen grunn. |
| On-Abnormal | Når serviceprosessen krasjer, må du starte tjenesten på nytt. Imidlertid, hvis applikasjonen kommer rent, ikke start den på nytt. Det er mer nyttig for Cron-Jobs som tjenester som trenger å gjøre en oppgave pålitelig, men som ikke trenger å løpe hele tiden. |
| på failure | Mye som på-abnormal, men den starter også på nytt når applikasjonen kommer ut, men med en ikke-null utgangskode. Ikke-null exit-koder betyr generelt at det skjedde en feil. |
| Nei | SystemD vil ikke starte tjenesten på nytt automatisk. Generelt nyttig for å få tilgang til andre SystemD -funksjoner som logging uten omstartfunksjonen. |
WorkingDirectory = kan håndheve en arbeidskatalog når du starter søknaden din. Verdien må være en absolutt katalogsti. Arbeidskatalog brukes når du bruker relative stier i applikasjonens kode. For vår Penguins -tjeneste kan det være:
WorkingDirectory =/Srv/Penguin-Web-App/
Da er sikkerhet viktig, slik at du generelt ikke vil starte tjenesten din med rotrettigheter. Bruker = og Group = lar deg angi bruker- eller gruppenavnet eller UID/GID som applikasjonen din vil bli lansert. For eksempel:
Bruker = Penguin-Web
Gruppe = pingvin-web
Miljøfil = er et kraftig alternativ. Applikasjoner som kjører som tjenester trenger ofte konfigurasjons- og miljøfiler gjør det mulig å angi konfigurasjonen på to måter:
- Applikasjonen kan lese direkte miljøvariabelen.
- Men du kan også angi forskjellige kommandolinjeargumenter på applikasjonen din uten å endre tjenestefilen.
Syntaksen til denne filen er enkel: du skriver inn miljøvariabelen, det like store tegnet = og deretter dens verdi. Så legger du den absolutte banen til miljøfilen din i miljøfilen.
Så eksempel:
Miljøfil =/etc/Penguin-Web-App/Environment
Og/etc/penguin-web-app/miljøfilen inneholder:
LIST_PORT = 8080
Da vil Penguins -nettappen vår ha tilgang til listen_port miljøvariabel 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 den 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 Penguins-server, ville det være Penguin-Web-App.service.
Deretter må du fortelle SystemD at du la til en ny tjeneste, så du må skrive denne kommandoen:
$ sudo SystemCTL Daemon-Reload
Ok 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å, tid til å starte tjenesten:
$ sudo SystemCTL Start Penguin-Web-App.service
Hvis den mislykkes med en enhet, ikke funnet feil som denne:
$ sudo SystemCTL Start Penguin-Web-App.service
Kunne ikke starte Penguin-Web-App.Service: Enhet ikke funnet.
Det betyr at distribusjonen din ikke støtter katalogen, eller at du ikke navngav riktig tjenestefilen din. Sørg for å sjekke ut.
Hvis du setter opp tjenesten din med WantedBy = og vil at tjenesten din starter automatisk, må du aktivere den, med denne kommandoen:
$ sudo SystemCTL Aktiver Penguin-Web-App.service
Den kule tingen med en tjeneste er at den går i bakgrunnen. Problemet: Hvordan vite om det kjører ordentlig og om det kjører hvis det kjører i bakgrunnen? Ikke bekymre deg, SystemD -teamet tenkte på det også og ga en kommando for å se om det kjører ordentlig, siden hvor mye tid osv.:
$ SystemCTL Status Penguin-Web-App.service
Konklusjon
Gratulerer! Du kan nå få applikasjonene dine til å administrere uten at du bryr deg om å starte den på nytt manuelt 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 loggingssystemet på den nye tjenesten og bygge mer pålitelige servere!