Phenquestions
Met zijn diensten maakt systemd dit allemaal makkelijker, echt makkelijker. Zodra je iets wilt dat je applicatie bewaakt en er gemakkelijk controle over heeft, is systemd de juiste keuze, en dat ga ik hier uitleggen!
Waar zijn Systemd-services
Om een nieuwe service toe te voegen, moet je deze vraag beantwoorden. Zoals altijd in systemd, hangt het ervan af of de service alleen voor uw gebruiker is of voor het hele systeem. We zullen ons concentreren op hoe systemd werkt voor hele systeemservices.
De exacte locatie hangt af van waarom en hoe de service is geïnstalleerd. Als de service is geïnstalleerd door een pakketbeheerder, bevindt deze zich over het algemeen in /usr/lib/systemd/system. Voor software die u ontwikkelt of diegene die systemd zelf niet ondersteunt, plaatst u het servicebestand in /usr/local/lib/systemd/system. Houd er echter rekening mee dat sommige distributies deze map in /usr/local . niet ondersteunen. Tot slot, als u een bestaande systemd-service wilt configureren, is /etc/systemd/system de juiste keuze.
In deze mappen vindt u meerdere bestandsextensies zoals *.stopcontact, *.doel of *.onderhoud. We gaan ons natuurlijk focussen op het laatste. systemd gebruikt de bestandsnaam als de naam van de service bij het starten of stoppen enz. Dus over het algemeen bevatten bestandsnamen in service alleen alfanumerieke tekens samen met koppeltekens en onderstrepingstekens. Tijdens de ontwikkeling raad ik aan om het in uw documenten te maken en het vervolgens naar de systeemlocatie te kopiëren wanneer u klaar bent, dat zou u problemen voorkomen als u tijdens het bewerken opslaat.
OK, dus maak uw servicebestand aan in uw documenten. Nu zijn we klaar om te bekijken hoe we dit bestand moeten schrijven.
[Opmerking: zie mogelijk bugrapport in het commentaargedeelte van deze blogpost]
Description=Penguins Web Application HTTP-server (draaiend in poort 8080)
WantedBy=meerdere gebruikers.doelwit
[Onderhoud]
Type=eenvoudig
ExecStart=/usr/bin/python3 /usr/local/bin/pinguïn-web-app/main.py
Opnieuw opstarten=altijd
Het bestandsformaat ligt in feite dicht bij ini. Ik weet dat het misschien raar is, aangezien ini-bestanden vaak in Windows worden gevonden, maar zo werkt het. Het servicebestand is eerst verdeeld in 2 secties: [Unit] en [Service]. Elke sectie configureert een specifiek aspect van systemd: [Unit] bevat elementen die worden gedeeld door alle systemd unit-bestanden, terwijl [Service] alleen bedoeld is voor configuratie die specifiek is voor het opzetten van een nieuwe service.
Vervolgens wordt de sectie geconfigureerd met eigenschappen zoals Description= of ExecStart=. De waarde wordt gescheiden van de eigenschapsnaam door het gelijkteken = zonder spatie.
Laten we teruggaan naar het hierboven getoonde bestand. Het beschrijft een service die is ontworpen om een in Python geschreven web-app over pinguïns uit te voeren. systemd start het opnieuw wanneer het proces wordt afgesloten en start de server bij het opstarten van de server als u het inschakelt met de opdracht systemctl enable. Gaaf he?
Maar misschien gaat je volgende web-app niet over pinguïns - en dat is jammer - en het is niet geschreven in Python. In dit geval wil je meer weten over de mogelijke configuraties.
Eigenschappen van Systemd Services
Laten we ons eerst concentreren op de eigenschappen in [Eenheid]:
Beschrijving= gaat gewoon over het geven van een duidelijke beschrijving van wat de service doet. Het wordt weergegeven in de servicelijst, servicelogboeken, dus u wilt dat het beschrijvend is, maar het moet in één regel en één zin blijven.
WantedBy= maakt het mogelijk om tegen systemd te zeggen: wanneer dit ding is gestart, start ik ook. Over het algemeen zet je de naam van een doel. Voorbeelden van veelvoorkomende doelen:
- meerdere gebruikers.doel: wanneer de server in orde is en klaar is om opdrachtregeltoepassingen uit te voeren
- grafisch.doel: wanneer GNOME of KDE gereed is
- netwerk-up.doel: wanneer de server correct is aangesloten op een netwerk
OK voor het begin zijn deze eigenschappen van [Eenheid] genoeg. Laten we nu eens kijken naar [Service].
Type= helpt systemd om te weten of een service actief is. Hier zijn veelvoorkomende typen:
- eenvoudig is waarschijnlijk de meest gebruikte: systemd beschouwt het proces dat u start als degene die de service uitvoert. Als het proces stopt, wordt de service ook als gestopt beschouwd, enz.
- forking heeft de voorkeur voor toepassingen die zijn geschreven als server, maar zonder de hulp van een servicebeheersysteem service. In principe verwacht het dat het gelanceerde proces zich zal splitsen en die fork wordt beschouwd als het laatste proces voor de service. Om nauwkeuriger te zijn, kunt u systemd ook helpen met een PID-bestand, waarbij de PID van het te volgen proces wordt geschreven door de gestarte applicatie.
ExecStart= is waarschijnlijk het belangrijkste voor een service: het geeft aan welke applicatie moet worden gestart bij het starten van de service. Zoals je kunt zien in de Penguin-service, heb ik /usr/bin/python3 gebruikt en niet meteen python3. Het is omdat de systemd-documentatie expliciet aanbeveelt om absolute paden te gebruiken om verrassingen te voorkomen.
Maar dat is ook om een andere reden. Het beheersysteem van andere services is meestal gebaseerd op Shell-scripts. Systemd voert om prestatieredenen echter standaard geen shell uit. U kunt dus niet rechtstreeks een shell-opdracht geven in ExecStart= provide. U kunt echter nog steeds een shellscript gebruiken door te doen:
ExecStart=/usr/bin/bash /usr/local/bin/launch-pinguïn-server.shNiet zo moeilijk toch? Houd er rekening mee dat als u een proces moet uitvoeren om aan te geven dat uw service netjes moet stoppen, ExecStop= bestaat, evenals ExecReload= voor het opnieuw laden van services.
Restart= stelt u in staat om expliciet te vertellen wanneer de service opnieuw moet worden gestart. Dit is een van de belangrijke kenmerken van systemd: het zorgt ervoor dat je service zo lang blijft als je wilt, dus let goed op deze optie.
| Opnieuw opstarten= | Betekenis |
| altijd | systemd zal het blijven herstarten wanneer het stopt of crasht. Nou, totdat je systemctl doet stop servicenaam.onderhoud. Het is perfect voor servers en online services, omdat je liever weinig nutteloze herstarts hebt dan dat je de service handmatig opnieuw moet opstarten zonder enige reden. |
| on-abnormaal | Wanneer het serviceproces crasht, start u de service opnieuw. Als de toepassing echter netjes wordt afgesloten, start deze dan niet opnieuw op. Het is handiger voor cron-jobs zoals services die een taak betrouwbaar moeten uitvoeren, maar niet altijd hoeven te worden uitgevoerd. |
| bij-mislukking | Net als on-abnormaal, maar het herstart de service ook wanneer de toepassing netjes wordt afgesloten, maar met een afsluitcode die niet nul is. Afsluitcodes die niet nul zijn, betekent over het algemeen dat er een fout is opgetreden. |
| Nee | systemd zal de service niet automatisch herstarten. Over het algemeen handig om toegang te krijgen tot andere systeemfuncties, zoals loggen zonder de herstartfunctie. |
WorkingDirectory= kan een werkdirectory afdwingen bij het starten van uw applicatie. De waarde moet een absoluut directorypad zijn. Werkmap wordt gebruikt wanneer u relatieve paden gebruikt in de code van uw toepassing. Voor onze pinguïnservice kan het zijn:
WorkingDirectory=/srv/pinguïn-web-app/Dan is beveiliging belangrijk, dus u wilt uw service over het algemeen niet starten met root-rechten. Met User= en Group= kunt u de gebruikers- of groepsnaam of UID/GID instellen waaronder uw applicatie wordt gestart. Bijvoorbeeld:
Gebruiker=pinguïn-webGroep=pinguïn-web
EnvironmentFile= is een krachtige optie. Toepassingen die als services worden uitgevoerd, hebben vaak configuratie- en omgevingsbestanden nodig om die configuratie op twee manieren in te stellen:
- De applicatie kan de omgevingsvariabele direct lezen.
- Maar u kunt ook verschillende opdrachtregelargumenten voor uw toepassing instellen zonder het servicebestand te wijzigen.
De syntaxis van dit bestand is eenvoudig: u typt de naam van de omgevingsvariabele, het gelijkteken = en vervolgens de waarde ervan. Vervolgens plaatst u het absolute pad van uw omgevingsbestand in de eigenschap EnvironmentFile.
Dus voorbeeld:
EnvironmentFile=/etc/pinguïn-web-app/environmentEn het bestand /etc/penguin-web-app/environment bevat:
LISTEN_PORT=8080Dan heeft onze pinguïns-webapp toegang tot de omgevingsvariabele LISTEN_PORT en luistert naar de verwachte poort.
Sla de nieuw gemaakte Systemd-service op en start deze
Dus als je mijn advies hebt opgevolgd, heb je je servicebestand in je thuismap bewerkt. Zodra u tevreden bent, kopieert u dat bestand naar /usr/local/lib/systemd/system, ervan uitgaande dat uw distributie dat pad ondersteunt. De bestandsnaam van uw servicebestand is de servicenaam. Deze bestandsnaam moet eindigen op .onderhoud. Voor onze pinguïns-server zou dit bijvoorbeeld pinguin-web-app zijn.onderhoud.
Vervolgens moet je systemd vertellen dat je een nieuwe service hebt toegevoegd, dus je moet deze opdracht typen:
$ sudo systemctl daemon-reloadOké, nu is systemd op de hoogte van je nieuwe service, ervan uitgaande dat je bestand geen syntaxisfout bevat. Het is tenslotte je eerste bestand, dus de kans is groot dat je fouten maakt. U moet deze opdracht hierboven uitvoeren bij elke update in uw servicebestand.
Nu, tijd om de service te starten:
$ sudo systemctl start pinguïn-web-app.onderhoudAls het mislukt met een Unit not found-fout zoals deze:
$ sudo systemctl start pinguin-web-app.onderhoudKan pinguin-web-app niet starten.service: Eenheid niet gevonden.
Het betekent dat uw distributie de map niet ondersteunt of dat u uw servicebestand niet correct heeft genoemd. Kom zeker eens kijken.
Als u uw service instelt met WantedBy= en wilt dat uw service automatisch start, moet u deze inschakelen met dit commando:
$ sudo systemctl pinguin-web-app inschakelen.onderhoudHet leuke van een service is dat deze op de achtergrond draait. Het probleem: hoe weet je of het goed werkt en of het werkt als het op de achtergrond draait?? Maak je geen zorgen, het systemd-team heeft daar ook over nagedacht en een opdracht gegeven om te zien of het goed werkt, sinds hoeveel tijd, enz.:
$ systemctl status pinguïn-web-app.onderhoudConclusie
Proficiat! U kunt uw applicaties nu laten beheren zonder dat u ze elke keer handmatig opnieuw moet opstarten. Nu raad ik je aan om ons andere artikel over systemd logs te lezen: Master journalctl: begrijp systemd logs. Daarmee kunt u het krachtige logsysteem op uw nieuwe service gebruiken en betrouwbaardere servers bouwen!
