Linux concept: systemd

1. De basis

De taak van systemd is de systeem- en dienstbeheerder voor Linux zijn. Wanneer je machine opstart, start de kernel precies een programma rechtstreeks, en geeft het proces-ID 1 (PID 1). Op vrijwel elke gangbare distributie is dat programma systemd. Al het andere dat je ziet draaien, van een webserver tot een achtergrond-timer tot het aankoppelen van een schijf, is een kind dat systemd heeft gestart, volgt en weer kan stoppen.

Omdat het PID 1 is, is systemd bijzonder. Het is de voorouder van elk ander proces, het stopt nooit zolang het systeem draait, en als het zou crashen zou de kernel in paniek raken. Dus systemd moet voorzichtig zijn, klein in zijn kern, en betrouwbaar. Het doet zijn werk door een reeks beschrijvingsbestanden genaamd units te lezen en erop te handelen.

Het kernidee is de unit. Systemd denkt niet in termen van "programma's" of "scripts". Het denkt in units: kleine declaratieve bestanden die iets beschrijven wat het moet beheren en hoe. De meest voorkomende soort is de service, maar er zijn units voor koppelpunten, timers, sockets, netwerkapparaten en hele systeemtoestanden. Elke unit heeft een naam die eindigt op een typesuffix, zoals ssh.service of graphical.target.

Het juiste mentale model: systemd is de ene beheerder die de hele machine draait, van de eerste seconde van het opstarten tot het afsluiten, en alles wat beheerbaar is op het systeem, een dienst, een koppeling, een timer, een target, wordt eraan beschreven als een unit.

Je praat meestal niet rechtstreeks met systemd. Je gebruikt zijn familie van commandoregel-gereedschappen, bovenal systemctl om units te besturen en journalctl om logs te lezen. Dit artikel gaat over de beheerder zelf: wat het is, hoe het je machine opstart, hoe units en targets samenhangen, hoe het processen volgt met control groups, en de verrassende hoeveelheid van een modern Linux-systeem die eigenlijk systemd met een andere pet op is. Het is geverifieerd tegen systemd versie 255.

1.1 Zien dat systemd PID 1 is

Je kunt met een commando bevestigen dat systemd de leiding heeft. Proces 1 is de beheerder, en het opstartprogramma /sbin/init is slechts een link ernaartoe:

$ ps -p 1 -o comm=
systemd

$ ls -l /sbin/init
/sbin/init → /lib/systemd/systemd

Decennialang was /sbin/init het echte eerste programma. Vandaag wijst het naar systemd, dat oude gewoonten en bootloaders laat werken terwijl systemd het eigenlijke werk doet.

1.2 De eerste blik: wat draait er

Om te zien wat systemd nu beheert, vraag je het zijn units op te sommen. Toestand lezen vereist geen speciale rechten:

$ systemctl                       # every unit currently loaded
$ systemctl status                # a tree of the whole system
$ systemctl list-units --type=service --state=running

De uitvoer toont elke unit, of systemd hem correct heeft ingelezen, en of hij actief is. Dat ene overzicht, alles op de machine in een lijst, is het praktische voordeel van een beheerder in plaats van een stapel losse scripts.

1.3 De belangrijkste unit-typen

Omdat "unit" het ene idee is dat systemd bindt, helpt het om de gangbare typen in een oogopslag te zien. De suffix op de naam van een unit vertelt je welk soort het is, en dezelfde werkwoorden (start, stop, enable, status) werken op allemaal:

De meeste dagen raak je alleen .service- en .target-units aan, maar de rest gebruikt exact hetzelfde gereedschap, wat een groot deel van de aantrekkingskracht van systemd is.

3. Een korte geschiedenis

Om systemd te begrijpen moet je weten wat het verving, want het veranderde hoe Linux opstart meer dan enig ander project in de laatste twintig jaar.

Het grootste deel van de Unix-geschiedenis was het eerste programma dat de kernel startte init, en het traditionele ontwerp was SysV init, genoemd naar AT&T's UNIX System V. Het was een reeks shellscripts onder /etc/init.d, in een vaste volgorde gedraaid door genummerde "runlevels". Het werkte, maar het was traag, omdat het diensten strikt na elkaar startte, en broos, omdat elke dienst een handgeschreven script was dat zijn eigen proces moest bijhouden. Een grote server opstarten kon minuten duren.

Pogingen om init te moderniseren kwamen eerst. Ubuntu leverde in 2006 Upstart, een gebeurtenisgestuurd systeem dat reageerde op dingen die gebeurden in plaats van op een vaste scriptvolgorde. Het was een echte verbetering, maar het behield de scriptzware stijl.

systemd, voor het eerst uitgebracht in 2010 door Lennart Poettering en Kay Sievers bij Red Hat, wilde init volledig vervangen met een nieuw ontwerp. De grote ideeen waren:

• Diensten beschrijven als kleine declaratieve unit-bestanden in plaats van shellscripts, zodat de beheerder, niet elk script, het zware werk doet.
• Onafhankelijke diensten parallel starten, en afhankelijkheden gebruiken om de volgorde uit te werken, voor een veel sneller opstarten.
• Elk dienstproces betrouwbaar volgen met kernel-control groups (cgroups), zodat een dienst en al zijn kinderen altijd te vinden en te stoppen zijn.
• Alle logs verzamelen in een gestructureerd journal in plaats van verspreide tekstbestanden.

De overstap ging niet zonder discussie. systemd is groot en doet veel meer dan de oude init, en neemt taken op zich zoals logging, netwerkinstellingen en apparaatbeheer die vroeger bij losse programma's hoorden. Sommige beheerders houden niet van deze reikwijdte, en een paar distributies (zoals Devuan, een systemd-vrije fork van Debian) vermijden het bewust. Maar op een standaard moderne installatie is systemd wat je machine opstart en draait, en het leren ervan is niet langer optioneel.

5. Gemiddelde gebruiksgevallen

Zodra de basis routine voelt, is de volgende stap om je eigen werk aan systemd te beschrijven. Hier houden units op iets te zijn wat de distributie levert en worden ze iets wat je zelf schrijft.

5.1 De anatomie van een unit-bestand

Een unit-bestand is een gewoon tekstbestand in "INI"-stijl: benoemde secties tussen vierkante haken, elk met Sleutel=Waarde-regels. Een service-unit gebruikt drie secties, en elk heeft een duidelijke taak:

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

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

[Install]
WantedBy=multi-user.target

Je bewaart dit als /etc/systemd/system/myapp.service, vertelt systemd zijn bestanden opnieuw in te lezen, en enablet het dan:

$ 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 sterkste redenen om een echte unit te verkiezen boven een handmatig gedraaid script: als je programma crasht, brengt systemd het automatisch terug.

5.2 Targets: units groeperen tot systeemtoestanden

Een target is een bijzondere unit die geen programma draait. In plaats daarvan groepeert het andere units en staat het voor een hele systeemtoestand. Targets zijn systemd's vervanging voor de oude genummerde runlevels:

Het systeem start op naar waar default.target naar wijst. Je kunt het lezen, wijzigen, of de draaiende machine in een andere toestand schakelen:

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

5.3 Timers: een moderne vervanging voor cron

Decennialang betekenden geplande taken cron. systemd biedt zijn eigen planner in de vorm van timer-units. Een timer is een kleine unit die zegt wanneer, gekoppeld aan een dienst die zegt wat. Het paar ziet er zo uit:

# backup.timer
[Unit]
Description=Nightly backup

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

De bijbehorende backup.service bevat de ExecStart= die het werk doet. Timers hebben echte voordelen boven cron: ze loggen naar het journal net als elke dienst, ze kunnen een gemiste run inhalen met Persistent=true, en je kunt ze allemaal met een commando opsommen:

$ systemctl list-timers            # every timer, next and last run time

7. Wat de meeste gebruikers niet weten

7.1 systemd is niet een programma, het is een hele vloot

Mensen zeggen "systemd" alsof het een enkele binary is, maar het is een grote verzameling programma's die samenwerken. De beheerder op PID 1 is slechts de kern; eromheen zitten tientallen gespecialiseerde daemons en gereedschappen. Een snelle blik onder /lib/systemd/ toont de schaal:

$ ls /lib/systemd/systemd-*
systemd-journald   systemd-logind    systemd-udevd
systemd-networkd   systemd-resolved  systemd-timesyncd
systemd-oomd       systemd-homed     ... (dozens more)

Elk neemt een taak op zich die vroeger bij een apart, onafhankelijk project hoorde:

Dit is precies wat de critici bedoelen met "systemd doet te veel" en de fans met "het is eindelijk consistent". Hoe dan ook, het verklaart waarom het project zo groot aanvoelt: het is niet een gereedschap, het is een samenhangende suite die veel taken tegelijk overnam.

7.2 Waar systemd zit in het hele opstarten

systemd start de machine niet vanaf niets; het neemt het halverwege een langere keten over. De volledige volgorde kennen vertelt je welk deel systemd's taak is en welk deel gebeurt voordat het uberhaupt laadt:

1. Firmware (UEFI or BIOS)   powers up and finds a boot device
2. Bootloader (GRUB)         loads the kernel and initramfs
3. Linux kernel              starts and detects hardware
4. initramfs                 tiny temporary root, mounts the real disk
5. systemd (PID 1)           takes over as the first real process
6. Targets reached           services started up to the default target
7. Login prompt or desktop   the system is ready

Alles tot en met stap 4 gebeurt voordat systemd bestaat, dus een fout daar, zoals een ontbrekende kernel of een kapotte bootloader, is niets wat systemd kan melden. Vanaf stap 5 is de machine systemd's verantwoordelijkheid, en het werkt omhoog door een keten van targets, elk een mijlpaal:

local-fs.target      →  filesystems mounted
       ↓
sysinit.target       →  early one-time setup done
       ↓
basic.target         →  sockets, timers, and paths ready
       ↓
multi-user.target    →  all normal services running
       ↓
graphical.target     →  desktop login on top

Elke target zegt dat hij After= de vorige moet komen en Wants= de diensten in zijn groep. systemd start alles wat het veilig kan parallel binnen elke fase, en dat is waarom een systemd-opstart zoveel sneller is dan de strikte een-voor-een volgorde van SysV init. Je kunt de exacte keten zien die je eigen opstarten begrensde met systemd-analyze critical-chain.

7.3 Een dienst "enablen" is gewoon een symbolische link

Het woord enable klinkt alsof het een verborgen schakelaar omzet. Het doet iets veel eenvoudigers: het maakt een symbolische link. De [Install]-sectie van een unit noemt de target die hem wil, zoals WantedBy=multi-user.target. De unit enablen maakt een symlink ernaartoe in de .wants-map van die target:

$ sudo systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service
               → /lib/systemd/system/nginx.service.

Bij het opstarten bereikt systemd multi-user.target, ziet de symlinks in zijn .wants-map, en start elke gelinkte unit. Dat is het hele mechanisme. Disablen verwijdert simpelweg de link, en een dienst maskeren linkt zijn naam naar /dev/null zodat niets hem kan starten. Zodra je dit weet, houdt enablen op magie te zijn en wordt het bestanden die je met ls kunt opsommen.

7.4 systemd praat met je over D-Bus

Wanneer je systemctl restart nginx draait, raakt het systemctl-programma nginx helemaal niet aan. Het stuurt een bericht naar systemd (PID 1) over D-Bus, de standaard berichtenbus die Linux-programma's gebruiken om met elkaar te praten. systemd ontvangt het verzoek, controleert of je het mag doen, doet het werk, en legt het resultaat vast. Dit ontwerp verklaart meerdere dingen:

• Een polkit-wachtwoordvenster kan verschijnen op een bureaublad, omdat D-Bus systemd laat vragen aan een autorisatiedienst of de actie is toegestaan.
• Elk programma kan diensten beheren door dezelfde bus te spreken, niet alleen systemctl; je kunt dat verkeer bekijken met busctl.
• systemctl is een dunne client. De intelligentie zit in de beheerder waarmee het praat, niet in het commando.

7.5 Het volgt processen per cgroup, zodat niets ontsnapt

Oude init-systemen volgden een dienst via zijn PID-bestand, en een programma dat slim forkte kon zich losmaken en als wees blijven draaien. systemd dicht dat gat: omdat elke dienst in zijn eigen cgroup leeft, blijft een verdwaald kind binnen dezelfde groep hoe het ook forkt. Wanneer systemd de dienst stopt, stopt het de hele cgroup, dus er blijven geen processen achter. Dit is waarom een moderne systemctl stop zoveel betrouwbaarder is dan de oude "dood de PID en hoop"-aanpak, en het is dezelfde verantwoording die systemd het exacte geheugengebruik van een dienst laat rapporteren.

7.6 Je kunt rechtstreeks naar een shell opstarten

Omdat targets gewoon systeemtoestanden zijn, kun je systemd bij het opstarten om een minimale toestand vragen door de kernel-commandoregel te bewerken. systemd.unit=rescue.target toevoegen start op naar een single-user reddingsshell; emergency.target geeft je de kaalste shell van allemaal, nuttig wanneer een kapotte /etc/fstab een normale opstart tegenhoudt. Dit is systemd's equivalent van de oude truc om single of een runlevelnummer toe te voegen, en het verandert "de machine start niet op" in een probleem dat je vaak vanaf dezelfde console kunt oplossen.

9. Veelgemaakte fouten

9.1 Mythe versus werkelijkheid

9.2 Andere valkuilen om te vermijden

• daemon-reload vergeten na het bewerken van een unit. Dit is de nummer-een oorzaak van "mijn wijziging deed niets". systemd gebruikt nog de gecachte kopie.
• Bestanden bewerken in /lib/systemd/system. De volgende pakketupdate overschrijft ze stilletjes. Houd je wijzigingen in /etc/systemd/system of een drop-in.
• Een gebruikersdienst zoeken in het systeemoverzicht. Een unit die met --user is gestart verschijnt niet in een gewone systemctl status. Voeg --user toe om hem te zien.
• De unit-naam verwarren met de procesnaam. De unit kan ssh.service zijn terwijl het draaiende programma sshd is. Gebruik tab-aanvulling of systemctl list-units om de exacte unit te vinden.
• Aannemen dat logs in /var/log/*.log staan. Op een standaard systemd-systeem is het journal de vastlegging; lees het met journalctl, niet door tekstbestanden te openen.
• Ordenen zonder vereisen, of andersom. After= stelt volgorde in maar geen afhankelijkheid; Requires= stelt afhankelijkheid in maar geen volgorde. Echte afhankelijkheden hebben meestal beide nodig.