Linux commando: systemctl

Je installeert een webserver, past de configuratie aan, en wilt hem nu en na elke herstart draaiend hebben. Je moet een dienst stoppen om hem bij te werken, kijken waarom er een is gecrasht, of uitzoeken wat automatisch bij het opstarten start. Op vrijwel elk modern Linux-systeem is het ene commando achter dit alles systemctl. Het is het bedieningspaneel voor systemd, het programma dat je diensten start, je schijven aankoppelt, en het hele systeem in de juiste volgorde opstart. Leer systemctl en je leert hoe een Linux-machine echt draait.

2. Waar komt de naam vandaan?

De naam bestaat uit twee delen die aan elkaar zitten: system plus ctl.

systemctl  =  SYSTEM + con-TROL

Het deel system wijst naar systemd, waarvan de naam zelf "system daemon" betekent (de afsluitende d is de klassieke Unix-conventie voor een achtergronddaemon, zoals in sshd of httpd). Dus systemctl is het gereedschap dat de system daemon bestuurt.

De uitgang ctl is kort voor control, en het is een huisstijl in de hele systemd-familie. Zodra je het patroon ziet, wordt een lange lijst met gereedschapsnamen opeens logisch:

Dus systemctl lees je als "het besturingsprogramma voor de systeembeheerder". Het is het centrale lid van de familie: de anderen beheren een stukje van het systeem, terwijl systemctl de units beheert die het geheel vormen.

4. Eenvoudige toepassingen

Vier werkwoorden dekken bijna al het dagelijkse dienstwerk: start, stop, restart en reload. Elk neemt een of meer unit-namen. De .service-uitgang is optioneel; als je het type weglaat, gaat systemd uit van .service.

4.1 Een dienst starten en stoppen

start activeert een unit nu; stop deactiveert hem nu. Geen van beide beinvloedt wat er gebeurt bij de volgende herstart.

$ sudo systemctl start nginx      # bring nginx up now
$ sudo systemctl stop nginx       # shut nginx down now

Deze commando's zijn stil bij succes: geen bericht is goed bericht. Draai daarna systemctl status nginx, of controleer de exit-code, om de wijziging te bevestigen.

4.2 Herstarten na een wijziging: restart

Wanneer je het configuratiebestand van een programma wijzigt, stopt restart de dienst en start hem opnieuw zodat de nieuwe instellingen van kracht worden:

$ sudo systemctl restart nginx    # full stop, then start

Een herstart onderbreekt de dienst kort. Voor iets als een webserver betekent dat een kort moment waarop hij niet antwoordt, en daar helpt het volgende commando.

4.3 Herladen zonder de dienst te onderbreken: reload

reload vraagt de draaiende dienst om zijn configuratie opnieuw te lezen zonder te stoppen. Het houdt bestaande verbindingen in leven, zodat een webserver of database niet uitvalt:

$ sudo systemctl reload nginx     # re-read config, stay up

De valkuil: een dienst kan alleen herladen als de maker er ondersteuning voor schreef. Als het niet kan, krijg je een fout. Als je niet zeker weet welke je nodig hebt, herlaadt reload-or-restart als het kan en herstart anders:

$ sudo systemctl reload-or-restart nginx

6. Gevorderde toepassingen

6.1 Een unit op de juiste manier bewerken: systemctl edit

Bewerk nooit direct het unit-bestand van een leverancier onder /lib/systemd/system; een pakketupdate overschrijft het. Gebruik in plaats daarvan systemctl edit, dat een klein drop-in-overschrijfbestand maakt dat alleen de instellingen wijzigt die je noemt en het origineel met rust laat:

$ sudo systemctl edit nginx        # opens an override drop-in in an editor

Dit schrijft naar /etc/systemd/system/nginx.service.d/override.conf. Jouw regels daar winnen van die van de leverancier. Om het hele bestand te vervangen in plaats van erover te leggen, gebruik je systemctl edit --full. Na het bewerken moet systemd zijn configuratie opnieuw lezen, wat het volgende commando is.

6.2 Systemd zelf herladen: daemon-reload

Er zijn twee heel verschillende soorten "herladen", en ze door elkaar halen is een klassieke valkuil:

• systemctl reload nginx vertelt de nginx-dienst om zijn eigen config opnieuw te lezen.
• systemctl daemon-reload vertelt systemd zelf om alle unit-bestanden opnieuw te lezen.

Telkens als je een unit-bestand toevoegt, bewerkt of verwijdert, draai je daemon-reload zodat systemd de wijziging opmerkt, en herstart je daarna de betreffende dienst:

$ sudo systemctl daemon-reload     # systemd re-reads unit files
$ sudo systemctl restart nginx     # apply the new unit definition

Als je een unit bewerkt en je wijzigingen lijken genegeerd, is een gemiste daemon-reload meestal de reden.

6.3 Je eigen service-unit schrijven

Vroeg of laat wil je je eigen programma als beheerde dienst draaien, zodat het bij het opstarten start, herstart bij een fout, en naar het journal logt zoals elke andere unit. Dit doe je door een klein unit-bestand te schrijven onder /etc/systemd/system/. Een service-unit heeft drie secties:

$ sudo nano /etc/systemd/system/myapp.service

[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/opt/myapp/app.sh
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

Elke sectie heeft een duidelijke taak:

Na het maken van het bestand vertel je systemd erover en zet je het aan:

$ sudo systemctl daemon-reload      # systemd notices the new file
$ sudo systemctl enable --now myapp  # start it now and at every boot

De regel Restart=on-failure is een van de redenen om een echte unit te verkiezen boven een handmatig gedraaid script: systemd brengt je programma weer omhoog als het crasht.

6.4 Volgorde en vereisten bepalen

De sectie [Unit] is waar je zegt hoe een unit zich tot anderen verhoudt, en twee verschillende ideeen zijn makkelijk te verwarren: volgorde (wanneer) en vereiste (of):

De valkuil is dat volgorde en vereiste los staan. Requires= zegt dat de andere unit er moet zijn, maar het zegt niet om erop te wachten; je combineert het bijna altijd met After= om ook de volgorde goed te krijgen:

[Unit]
Requires=postgresql.service
After=postgresql.service

Wants= is de mildere en meer voorkomende keuze: het is wat enable achter de schermen voor je schrijft, en het voorkomt dat een falende afhankelijkheid je dienst met zich meesleurt.

6.5 Afhankelijkheden begrijpen: list-dependencies

Zodra units van elkaar afhangen, moet je vaak de hele boom zien. list-dependencies toont wat een unit binnenhaalt, en met --reverse, wat ervan afhangt:

$ systemctl list-dependencies nginx    # what nginx pulls in
$ systemctl list-dependencies --reverse nginx   # what depends on nginx

Zo beantwoord je "waarom start deze dienst?" en "wat breekt er als ik die stop?".

6.6 Een dienst beveiligen: sandboxing

Een van de meest onderbenutte krachten van systemd is dat de sectie [Service] een dienst in een sandbox kan opsluiten, waardoor kleiner wordt wat een gecompromitteerd programma kan bereiken. Je voegt deze toe als gewone directives, geen container nodig:

Je kunt meten hoe goed een dienst is dichtgezet met een ingebouwde scanner die elke unit een score geeft en voorstelt wat je toe kunt voegen:

$ systemd-analyze security nginx    # exposure score and per-setting advice

Voor een dienst die aan het internet is blootgesteld, kunnen een paar van deze regels een volledige systeemcompromittering in een ingeperkte veranderen. Voeg ze toe via systemctl edit zodat ze updates overleven.

6.7 Het echte unit-bestand zien: cat en show

systemctl cat drukt het exacte unit-bestand af dat systemd inlaadde, inclusief eventuele drop-ins die erbovenop liggen, zodat je de effectieve definitie ziet:

$ systemctl cat nginx              # the unit file plus any overrides

systemctl show gaat verder en dumpt elke opgeloste eigenschap als KEY=VALUE, wat de manier is om te controleren wat een instelling daadwerkelijk werd:

$ systemctl show nginx -p MemoryCurrent -p ExecStart

6.8 Maskeren: de sterkste uit-schakelaar

disable voorkomt dat een dienst bij het opstarten start, maar iets anders kan hem nog steeds als afhankelijkheid binnenhalen, of je kunt hem nog met de hand starten. mask is het absolute blok: het maakt de unit onmogelijk om te starten, door wie dan ook, totdat je hem unmaskt:

$ sudo systemctl mask nginx        # nginx cannot be started at all now
$ sudo systemctl unmask nginx      # allow it again

Gebruik maskeren wanneer je een dienst echt dood wilt hebben, bijvoorbeeld om de standaardwebserver van een distributie te vervangen door je eigen. Onder de motorkap linkt maskeren de unit aan /dev/null, wat sectie 7 uitlegt.

6.9 Targets: units groeperen in systeemtoestanden

Een target is een speciale unit die andere units groepeert, gebruikt om een hele systeemtoestand te beschrijven. Targets zijn de vervanging van systemd voor de oude runlevels:

Je kunt de boot-standaard bekijken, wijzigen, of het draaiende systeem in een andere target schakelen:

$ systemctl get-default                       # e.g. graphical.target
$ sudo systemctl set-default multi-user.target  # boot without a desktop next time
$ sudo systemctl isolate rescue.target          # switch to rescue mode now

6.10 Herstarten, uitschakelen en slaapstand

Omdat systemd de hele systeemtoestand beheert, bezit het ook het afsluiten en slapen. Deze werkwoorden vervangen de oudere losse commando's:

$ systemctl reboot         # restart the machine
$ systemctl poweroff       # shut down and power off
$ systemctl suspend        # sleep to RAM
$ systemctl hibernate      # sleep to disk

8. Beste praktijken

• Beslis bewust over "nu" en "bij boot". Voor een dienst die je permanent wilt, gebruik enable --now. Voor een eenmalige, gebruik gewoon start. Duidelijk zijn over welke je bedoelt, voorkomt verrassingen na een herstart.
• Verkies reload boven restart wanneer het bestaat. Een reload houdt verbindingen in leven; een restart onderbreekt ze even. Val terug op reload-or-restart als je twijfelt.
• Bewerk nooit direct leveranciers-unit-bestanden. Gebruik systemctl edit om een drop-in-overschrijving toe te voegen, zodat een pakketupdate je wijzigingen niet kan wissen.
• Draai daemon-reload na elke unit-bestandswijziging. Anders blijft systemd de oude definitie gebruiken en lijken je bewerkingen niets te doen.
• Geef je eigen programma een echte unit. Een kort [Unit]/[Service]/[Install]-bestand met Restart=on-failure verslaat een handmatig gedraaid script: het start bij boot, herstart bij een crash, en logt naar het journal.
• Sandbox diensten die aan het internet hangen. Voeg een paar regels toe zoals ProtectSystem=strict, PrivateTmp=true en NoNewPrivileges=true, en controleer het resultaat met systemd-analyze security.
• Controleer systemctl --failed regelmatig. Op een server is het de snelste manier om een dienst te vinden die stilletjes stierf.
• Gebruik systemctl cat om de waarheid te zien. Het toont de echte, effectieve unit inclusief overschrijvingen, wat gissen voorkomt over welk bestand van kracht is.
• Lees de handleiding als je twijfelt. Het gedrag is volledig gedocumenteerd; man systemctl en man systemd.unit zijn de naslag.

$ man systemctl         # the command and all its verbs
$ man systemd.service    # how to write a service unit
$ systemctl --help       # a quick summary of the commands

10. Samenvatting

Het commando systemctl is het bedieningspaneel voor systemd, en systemd draait alles op een moderne Linux-machine. Leer een handvol werkwoorden en een belangrijk onderscheid, en diensten beheren wordt kalm en voorspelbaar in plaats van giswerk.

• systemctl bevraagt en bestuurt systemd, de beheerder die elke dienst, koppeling en timer als een unit start.
• De naam betekent "system control", onderdeel van de systemd-familie naast journalctl en timedatectl.
• Het verving SysV-init-scripts door declaratieve unit-bestanden en parallel opstarten, en arriveerde met systemd in 2010.
• Beheer een draaiende dienst met start, stop, restart en reload; controleer hem met status.
• Het cruciale onderscheid: start/stop werken nu, enable/disable werken bij boot, en --now doet beide.
• Stel ja-of-nee met is-active, is-enabled en is-failed; toon toestand met list-units, list-unit-files en --failed.
• Schrijf je eigen dienst als een klein [Unit]/[Service]/[Install]-bestand, orden het met After=/Before=, en vereis anderen met Wants=/Requires=.
• Beveilig een dienst in zijn [Service]-sectie met sandboxing (ProtectSystem=, PrivateTmp=, NoNewPrivileges=), gescoord door systemd-analyze security.
• Bewerk units veilig met systemctl edit (een drop-in), draai daarna daemon-reload zodat systemd het opmerkt.
• Blokkeer een dienst volledig met mask; groepeer units en systeemtoestanden met targets zoals multi-user.target.
• Onder de motorkap is enablen een symlink in de .wants-map van een target, is maskeren een symlink naar /dev/null, en bereikt systemctl systemd via D-Bus.
• Een unit in /etc/systemd/system overschrijft altijd de leverancierskopie in /usr/lib/systemd/system, wat drop-ins updates laat overleven.
• Je hebt een tweede, persoonlijke systemd bereikbaar met --user, en alles wat beheerbaar is (dienst, timer, koppeling, target) is een unit.

Dit is de handige naslag om te bewaren:

systemctl status nginx           is it running, enabled, and healthy
systemctl start nginx            run it now
systemctl stop nginx             shut it down now
systemctl restart nginx          full stop then start
systemctl reload nginx           re-read config, stay up
systemctl enable nginx           start at boot (not now)
systemctl enable --now nginx     start at boot AND now
systemctl disable --now nginx    stop now AND at boot
systemctl is-active nginx        one-word running check
systemctl is-enabled nginx       one-word boot check
systemctl --failed               list everything that failed
systemctl list-units --type=service   loaded services
systemctl list-unit-files        every installed unit and its state
systemctl edit nginx             safe drop-in override
systemctl daemon-reload          reload unit files after editing
systemctl cat nginx              show the effective unit file
systemctl mask nginx             block a service completely
systemctl list-dependencies nginx     what it needs
systemd-analyze security nginx   score a service's sandboxing
systemctl --user status          your own user services
systemctl reboot                 restart the machine

Diensten goed beheren is een van de stille vaardigheden die een kalme serverbeheerder onderscheiden van een gestreste: het verschil tussen een site die na elke herstart netjes terugkomt en een die stilletjes vergeet een dienst te starten op het slechtst denkbare moment. Als je servers diensten hebben die een herstart niet overleven, wijzigingen die nooit van kracht lijken te worden, of een boot die niemand echt begrijpt, loont het om systemd goed in te richten voor het volgende incident, zodat de machine zich precies gedraagt zoals je verwacht.