Phenquestions
Med sina tjänster gör systemd allt detta enklare, riktigt lättare. Så snart du vill ha något som övervakar din applikation och enkel kontroll av den är systemd vägen att gå, och det är vad jag ska förklara här!
Var finns Systemd Services
För att lägga till en ny tjänst måste du svara på den här frågan. Som alltid i systemd beror det på om tjänsten endast är för din användare eller hela systemet. Vi fokuserar på hur systemd fungerar för hela systemtjänster.
Den exakta platsen beror på varför och hur tjänsten installerades. Om tjänsten installeras av en pakethanterare kommer den i allmänhet att finnas i / usr / lib / systemd / system. För programvara som du utvecklar eller de som inte stöder systemd i sig, lägger du servicefilen i / usr / local / lib / systemd / system. Tänk dock på att vissa distributioner inte stöder den här mappen i / usr / local. Slutligen, om du vill konfigurera en befintlig systemd-tjänst, / etc / systemd / system är vägen att gå.
Inuti dessa mappar kan du hitta flera filtillägg som *.uttag, *.mål eller *.service. Uppenbarligen kommer vi att fokusera på det sista. systemd använder filnamnet som tjänstens namn när den startas eller stoppas osv. Så i allmänhet innehåller filnamn i tjänst endast alfanumeriska tecken tillsammans med bindestreck och understrykningar. Under utvecklingen rekommenderar jag att du skapar den i dina dokument och sedan kopierar den till systemets plats när du är klar, det skulle undvika problem om du sparar mitt i redigeringen.
OK så skapa din servicefil i dina dokument. Nu är vi redo att granska hur man skriver den här filen.
[Obs: Se potentiell felrapport i kommentarsektionen i detta blogginlägg]
Beskrivning = Penguins Web Application HTTP-server (körs i port 8080)
WantedBy = fleranvändare.mål
[Service]
Typ = enkel
ExecStart = / usr / bin / python3 / usr / local / bin / penguin-web-app / main.py
Starta om = alltid
Filformatet är faktiskt nära ini. Jag vet att det kan vara konstigt med tanke på att ini-filer ofta finns i Windows men så fungerar det. Servicefilen är först uppdelad i två avsnitt: [Enhet] och [Service]. Varje avsnitt konfigurerar en specifik aspekt av systemd: [Enhet] innehåller element som delas av alla systemd-enhetsfiler medan [Service] endast är för konfigurationsspecifik för att konfigurera en ny tjänst.
Sedan konfigureras sektionen med egenskaper som Beskrivning = eller ExecStart =. Värdet separeras från egenskapens namn med lika tecken = utan mellanslag.
Låt oss gå tillbaka till filen som visas ovan. Den beskriver en tjänst utformad för att köra en webbapp skriven i Python om pingviner. systemd startar om det när processen avslutas och startar servern vid servern start om du aktiverar den med systemctl aktivera kommandot. Cool, eh?
Men du kanske är din nästa webbapp inte om pingviner - och det är synd - och det är inte skrivet i Python. I det här fallet vill du lära dig mer om de möjliga konfigurationerna.
Egenskaper hos Systemd Services
Låt oss först fokusera på egenskaperna i [Unit]:
Beskrivning = handlar bara om att ge en tydlig beskrivning av vad tjänsten gör. Den visas i servicelistan, tjänstloggar så att du vill att den ska vara beskrivande men den ska ligga kvar i en rad och en mening.
WantedBy = tillåter att säga till systemd: när den här saken startas, startar jag också. Generellt sätter du namnet på ett mål. Exempel på vanliga mål:
- fleranvändare.mål: när servern är OK och är redo att köra kommandoradsapplikationer
- grafiskt.mål: när GNOME eller KDE är redo
- nätverksuppkoppling.mål: när servern är korrekt ansluten till ett nätverk
OK till att börja med är dessa egenskaper hos [Enhet] tillräckliga. Låt oss ta en titt på [Service] nu.
Typ = hjälper systemd till hur man vet om en tjänst körs. Här är vanliga typer:
- enkel är förmodligen den vanligaste: systemd anser att processen du startar som den som gör tjänsten. Om processen slutar anser den att tjänsten också är stoppad osv.
- Forking är att föredra för applikationer som har skrivits för att vara en server men utan hjälp av ett servicehanteringssystem. I grund och botten förväntar sig den lanserade processen att gaffla och den gaffeln anses vara den slutliga processen för tjänsten. För att vara mer exakt kan du också hjälpa till med en PID-fil, där PID för processen att spåra skrivs av den lanserade applikationen.
ExecStart = är förmodligen det viktigaste för en tjänst: det preciserar vilken applikation som ska startas när tjänsten startas. Som du kan se i Penguin-tjänsten har jag använt / usr / bin / python3 och inte python3 direkt. Det beror på att systemdokumentation uttryckligen rekommenderar att använda absoluta banor för att undvika överraskningar.
Men det är också av en annan anledning. Andra services ledningssystem brukar baseras på Shell-skript. Systemd kör emellertid inte ett skal som standard av prestationsskäl. Så du kan inte tillhandahålla ett skalkommando direkt i ExecStart =. Du kan dock fortfarande använda ett skalskript genom att göra:
ExecStart = / usr / bin / bash / usr / local / bin / launch-penguin-server.shInte så svårt? Observera att om du behöver köra någon process för att signalera att din tjänst ska sluta rent, execStop = existerar, liksom ExecReload = för omladdning av tjänster.
Restart = låter dig uttryckligen berätta när tjänsten ska startas om. Detta är en av de viktigaste funktionerna i systemd: det ser till att din tjänst håller sig uppe så länge du vill, så var noga med detta alternativ.
| Starta om = | Menande |
| alltid | systemd fortsätter att starta om det när det avslutas eller kraschar. Tja, tills du systemctl stoppar servicenamnet.service. Det är perfekt för servrar och onlinetjänster eftersom du föredrar att få värdelösa omstarter än att behöva starta om tjänsten manuellt utan någon anledning. |
| on-onormal | Starta om tjänsten när serviceprocessen kraschar. Men om programmet avslutas rent, starta inte om det. Det är mer användbart för cron-jobb som tjänster som behöver göra en uppgift pålitligt men inte behöver köras hela tiden. |
| vid misslyckande | Precis som onormal, men det startar också om tjänsten när applikationen avslutas rent men med en utgångskod som inte är noll. Utgångskoder som inte är noll betyder i allmänhet att ett fel inträffade. |
| Nej | systemd startar inte om tjänsten automatiskt. Allmänt användbart för att få tillgång till andra systemfunktioner som loggning utan omstartsfunktionen. |
WorkingDirectory = kan genomdriva en arbetskatalog när du startar din applikation. Värdet måste vara en absolut katalogsökväg. Arbetskatalogen används när du använder relativa sökvägar i programmets kod. För vår pingvinstjänst kan det vara:
WorkingDirectory = / srv / penguin-web-app /Då är säkerhet viktigt så att du i allmänhet inte vill starta din tjänst med rootprivilegier. Användare = och Grupp = låter dig ställa in användar- eller gruppnamn eller UID / GID under vilket din applikation kommer att startas. Till exempel:
Användare = pingvin-webbGrupp = pingvin-nät
EnvironmentFile = är ett kraftfullt alternativ. Program som körs som tjänster behöver ofta konfiguration och miljöfiler gör det möjligt att ställa in den konfigurationen på två sätt:
- Applikationen kan läsa direkt miljövariabeln.
- Men du kan också ställa in olika kommandoradsargument till din applikation utan att ändra servicefilen.
Syntaxen för den här filen är enkel: du skriver namnet på miljövariabeln, likhetstecknet = och sedan dess värde. Sedan lägger du den absoluta sökvägen för din miljöfil till miljöfilegenskapen.
Så exempel:
EnvironmentFile = / etc / penguin-web-app / environmentOch filen / etc / penguin-web-app / miljö innehåller:
LISTEN_PORT = 8080Då kommer vår pingvins webbapp att ha tillgång till miljövariabeln LISTEN_PORT och lyssna på den förväntade porten.
Spara och starta den nyskapade Systemd-tjänsten
Så om du följde mitt råd redigerade du din servicefil i din hemkatalog. När du är nöjd kopierar du filen till / usr / local / lib / systemd / system, förutsatt att din distribution stöder den sökvägen. Filnamnet på din servicefil kommer att vara dess servicenamn. Det här filnamnet måste sluta med .service. Till exempel, för vår pingvinsserver, skulle det vara penguin-web-app.service.
Sedan måste du berätta för systemd att du har lagt till en ny tjänst, så du måste skriva det här kommandot:
$ sudo systemctl daemon-reloadOkej nu är systemd medveten om din nya tjänst, förutsatt att din fil inte innehåller ett syntaxfel. Det är ju din första fil så det är troligt att du gör misstag. Du måste köra det här kommandot ovan för varje uppdatering i din servicefil.
Nu är det dags att starta tjänsten:
$ sudo systemctl starta penguin-web-app.serviceOm det misslyckas med en enhet som inte hittades fel som den här:
$ sudo systemctl starta penguin-web-app.serviceDet gick inte att starta penguin-web-app.service: Enheten hittades inte.
Det betyder att din distribution inte stöder katalogen eller att du inte namngav din servicefil korrekt. Var noga med att kolla in.
Om du ställer in din tjänst med WantedBy = och vill att din tjänst startar automatiskt måste du aktivera den med det här kommandot:
$ sudo systemctl aktiverar penguin-web-app.serviceDet coolaste med en tjänst är att den körs i bakgrunden. Problemet: hur man vet om det körs ordentligt och om det körs om det körs i bakgrunden? Oroa dig inte, systemd-teamet tänkte också på det och gav ett kommando för att se om det går ordentligt, eftersom hur mycket tid osv:
$ systemctl status penguin-web-app.serviceSlutsats
Grattis! Du kan nu få dina applikationer hanterade utan att du bryr dig om att starta om den manuellt varje gång. Nu rekommenderar jag dig att läsa vår andra artikel om systemd-loggar: Master journalctl: förstå systemd-loggar. Med det kan du använda det kraftfulla loggningssystemet på din nya tjänst och bygga mer pålitliga servrar!
