Linux concept: SysV init

1. De basis

SysV init (spreek uit als "System Five init") is het traditionele init-systeem voor Unix en Linux: de software die de kernel als eerste start en die daarna de rest van de machine tot leven brengt. Zoals elk init-systeem draait zijn kernprogramma als proces-ID 1 (PID 1) en blijft het in leven tot het afsluiten. Wat het "SysV" maakt, is hoe het bepaalt wat er gestart wordt: een vaste set genummerde systeemtoestanden genaamd runlevels, en een map met shell-scripts die het op volgorde draait om elke toestand binnen te gaan of te verlaten.

Er zijn drie bewegende delen, en zodra je die ziet, valt het hele systeem op zijn plek:

• Het programma /sbin/init, dat als PID 1 draait, de ouder van elk ander proces.
• Een enkel configuratiebestand, /etc/inittab, dat init vertelt in welk runlevel het moet opstarten en wat het in elk daarvan moet doen.
• Een map met start/stop-scripts, /etc/init.d, een script per dienst, plus een set rcN.d-mappen vol symbolische links die de volgorde bepalen.

Dat is het hele mentale model. init is een eenvoudige verdeler; het echte werk van het starten van een dienst zit in een gewoon shell-script dat de woorden start en stop begrijpt. Deze eenvoud was de grote kracht van SysV init (iedereen die een shell-script kon schrijven, kon een dienst toevoegen) en, zoals we zullen zien, zijn grote zwakte (init zelf begreep vrijwel niets van de diensten die het startte).

Het juiste mentale model: SysV init is een verdeler die genummerde runlevels afloopt en met de hand geschreven shell-scripts draait om diensten te starten en te stoppen. Het start programma's, maar in tegenstelling tot systemd houdt het er geen echt toezicht op.

1.1 Wat PID 1 bijzonder maakt

Proces 1 zijn is niet zomaar een klein nummer; het brengt taken met zich mee die de kernel aan geen enkel ander proces geeft. Elk init-systeem, SysV init inbegrepen, moet ze dragen, omdat het het ene proces is waar het hele systeem omheen is gebouwd:

• Het is de voorouder van alles. Wanneer de ouder van een proces sterft, wordt dat proces een wees, en de kernel geeft het aan PID 1 om voor te zorgen. Zo wordt init de adoptieouder van elk verdwaald proces op de machine.
• Het moet zombies opruimen. Wanneer een proces stopt, blijft het in de procestabel staan als een zombie tot zijn ouder de afsluitstatus ophaalt met wait(). Voor de wezen die het adopteert, is die ouder init. Als init ze niet zou opruimen, zou de procestabel zich langzaam vullen met dode vermeldingen, dus opruimen is een permanente achtergrondtaak van PID 1.
• Het kan niet zomaar stoppen. PID 1 moet in leven blijven gedurende het hele leven van het systeem. Als het sterft, is er geen proces meer over om de gebruikersruimte te beheren, en de kernel raakt in paniek.
• Het krijgt een bijzondere signaalbehandeling. De kernel past geen standaard signaalacties toe op PID 1, zodat een verdwaald signaal niet per ongeluk het ene proces kan doden waar het systeem van afhangt.

Dit is de moeite waard om te weten, omdat het het deel van init is dat nooit is veranderd. SysV init, Upstart en systemd behandelen runlevels, units en diensten heel verschillend, maar elk van hen moet wezen adopteren, zombies opruimen en nooit stoppen. Het is de onherleidbare kern van PID 1 zijn.

1.2 Waar SysV init vandaag de dag nog leeft

Op een moderne systemd-machine is /sbin/init niet langer het oude init-programma. Het is een symbolische link naar systemd, die de oude naam en bootloaders laat werken:

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

Toch is de SysV-indeling nog overal om je heen, omdat systemd bewust compatibel blijft. De onderstaande mappen en commando's zijn de SysV-wereld; op een systemd-systeem vormen ze een compatibiliteitslaag, maar op een echt SysV-systeem zijn ze het systeem:

$ ls -d /etc/rc*.d
/etc/rc0.d  /etc/rc1.d  /etc/rc2.d  /etc/rc3.d
/etc/rc4.d  /etc/rc5.d  /etc/rc6.d  /etc/rcS.d

$ ls /etc/init.d | head -4
anacron
bluetooth
cron
mysql

1.3 De runlevels in een oogopslag

Een runlevel is een genummerde systeemtoestand die zegt welke groep diensten zou moeten draaien. init kan op elk moment in precies een runlevel zijn, en je wisselt van toestand door het te vertellen te veranderen. De nummers zijn een langlopende afspraak:

Twee hiervan zijn niet echt "toestanden" waar je in blijft: runlevel 0 binnengaan halt de machine en 6 binnengaan herstart hem. Daarom stel je je standaard-runlevel nooit in op 0 of 6: het systeem zou eindeloos afsluiten of herstarten. De betekenis van 2 tot en met 5 is slechts een afspraak en verschilt per distributie, een punt waar we in sectie 7 op terugkomen.

3. Een korte geschiedenis

init is een van de oudste ideeen in Unix, ouder dan Linux zelf. Een of andere vorm van een "init"-proces bestaat al sinds het vroegste Unix in de jaren zeventig, omdat een systeem altijd een eerste proces nodig heeft om de rest te starten.

Het specifieke ontwerp dat we SysV init noemen, kwam van AT&T UNIX System V in 1983, dat het idee van genummerde runlevels en een centraal bestand /etc/inittab vastlegde. Dit was het model dat Linux overnam. De meest gebruikte Linux-implementatie, het pakket sysvinit, werd begin jaren negentig geschreven door Miquel van Smoorenburg en werd de standaard-init op vrijwel elke Linux-distributie voor de volgende twee decennia.

Lange tijd werkte het gewoon, en niemand dacht er veel over na. Maar naarmate machines meer cores en meer diensten kregen, begonnen de zwakke plekken pijn te doen: het startte diensten strikt een voor een, dus opstarten was traag; elke dienst was een broos, met de hand geschreven script; en init kon een dienst niet echt volgen zodra die eenmaal gestart was. Twee vervangers zetten zich in om dit op te lossen:

• Upstart, in 2006 uitgebracht door Ubuntu, reageerde op gebeurtenissen in plaats van een vaste scriptvolgorde te volgen, maar behield de scriptzware stijl.
• systemd, uitgebracht in 2010, verving init volledig met declaratieve unit-bestanden, parallel starten en betrouwbaar procesvolgen via control groups.

SysV init is niet helemaal dood. Een handvol distributies houdt het bewust in stand, container-basisimages gebruiken soms een piepklein init, en elke gangbare distributie levert nog steeds het commando service en de map /etc/init.d zodat oude scripts blijven werken. Het leren gaat minder om het in productie draaien en meer om het lezen van de vele systemen en scripts die het nog steeds veronderstellen.

Dit zijn de distributies om naar te grijpen als je bewust zonder systemd wilt draaien. Merk op dat Slackware technisch gezien BSD-stijl is in plaats van strikt SysV, maar in dagelijks gebruik voelt het hetzelfde: gewone shell-scripts die diensten in een vaste volgorde starten.

systemd is ook niet het enige alternatief. Naast klassiek SysV init staat een familie lichtere init-systemen die de klein-en-eenvoudige geest behouden en er tegelijk echt diensttoezicht aan toevoegen: OpenRC (de standaard op Gentoo en Alpine, die nog steeds /etc/init.d-scripts gebruikt), en het minimalistische runit, s6 en dinit. Ze zijn vooral van belang op lichtgewicht of systemd-vrije systemen, maar ze laten zien dat de keuze nooit simpelweg "SysV of systemd" was.

5. Gemiddelde gebruiksgevallen

Om verder te gaan dan diensten draaien, moet je de twee bestanden begrijpen die SysV init aandrijven: de configuratie /etc/inittab en de rcN.d-symlinkmappen.

5.1 /etc/inittab lezen

Op een echt SysV-systeem is /etc/inittab het hoofdschakelbord. Elke regel heeft vier velden gescheiden door dubbele punten:

id:runlevels:action:process

Een typische inittab ziet er zo uit:

id:5:initdefault:                      # boot into runlevel 5 by default
si::sysinit:/etc/init.d/rcS            # one-time early setup
l3:3:wait:/etc/init.d/rc 3            # entering runlevel 3: run the rc script for 3
l5:5:wait:/etc/init.d/rc 5            # entering runlevel 5: run the rc script for 5
ca::ctrlaltdel:/sbin/shutdown -r now  # what Ctrl-Alt-Del does
1:2345:respawn:/sbin/getty 38400 tty1 # a login prompt on tty1, restarted if it dies

Twee regels dragen de meeste betekenis. De initdefault-regel stelt het runlevel in waarin de machine opstart; het nummer wijzigen wijzigt de standaard-opstarttoestand. De respawn-regels zijn de ene plek waar init echt ergens toezicht op houdt: als een getty (de inlogprompt) stopt, start init het opnieuw, en daarom verschijnt er een verse inlogprompt op het moment dat je uitlogt op een tekstconsole.

5.2 De rcN.d-mappen: S- en K-links

Wanneer init een runlevel binnengaat, draait het een script, /etc/init.d/rc N, dat in de bijbehorende map /etc/rcN.d kijkt. Die map staat vol symbolische links terug naar de echte scripts in /etc/init.d, en de linknamen coderen de volgorde en de actie:

$ ls -l /etc/rc2.d
K01speech-dispatcher → ../init.d/speech-dispatcher
S01cron              → ../init.d/cron
S01mysql             → ../init.d/mysql
S01docker            → ../init.d/docker

De naamgevingsregel is eenvoudig en vormt het hart van SysV init:

• Een link die begint met S betekent Start: draai het script met start bij het binnengaan van dit runlevel.
• Een link die begint met K betekent Kill: draai het script met stop bij het binnengaan van dit runlevel.
• De twee cijfers na de letter bepalen de volgorde. Scripts draaien in numerieke volgorde, dus S10 draait voor S20. Zo kun je een database starten voor de webserver die hem nodig heeft.

Klassieke systemen spreiden de nummers uit (S20apache2, K80apache2) om de volgorde met de hand af te stemmen. Nieuwere Debian en Ubuntu berekenen de volgorde uit afhankelijkheden en geven vrijwel alles S01, en daarom laat het voorbeeld hierboven zoveel S01-links zien.

5.3 Een dienst inschakelen op de SysV-manier

Je maakt die symlinks zelden met de hand. Elke distributiefamilie heeft een gereedschap dat ze voor je aanmaakt en verwijdert, door de afhankelijkheidskoppen binnen het init-script te lezen:

# Debian and Ubuntu
$ sudo update-rc.d cron defaults   # create S/K links in the default runlevels
$ sudo update-rc.d cron remove     # remove all its links

# Red Hat and SUSE
$ sudo chkconfig cron on           # enable at boot
$ sudo chkconfig --list cron       # show its runlevels

Dit is het SysV-equivalent van systemctl enable. In beide werelden betekent een dienst "inschakelen" dat je op een vaste plek vastlegt dat hij bij het opstarten moet starten. Hier is dat verslag een symlink; onder systemd is het ook een symlink, in een .wants-map.

7. Wat de meeste gebruikers niet weten

7.1 De hele "database" bestaat alleen uit symlinknamen

SysV init heeft geen register, geen database en geen configuratieformaat voor "welke diensten starten bij het opstarten". Het hele antwoord is gecodeerd in de namen van symbolische links in de rcN.d-mappen. De letter (S of K) zegt starten of stoppen, de twee cijfers zeggen de volgorde, en de rest is de scriptnaam. Dat is alles. Je kunt het volledige opstartplan voor een runlevel lezen met een gewone ls, en het wijzigen door links te hernoemen of te verwijderen. Het is prachtig doorzichtig en, op schaal, pijnlijk handmatig, en daarom wikkelde elke distributie het in gereedschappen als update-rc.d en chkconfig.

7.2 Runlevel-nummers betekenen iets anders op verschillende distributies

Een veelvoorkomende en gevaarlijke verrassing: de nummers 2 tot en met 5 zijn slechts afspraken, en de twee grote Unix-families waren het er nooit over eens. Op systemen in Red Hat-stijl is runlevel 3 meergebruikers-tekstmodus en voegt 5 een grafisch bureaublad toe. Op systemen in Debian-stijl zijn runlevels 2 tot en met 5 standaard allemaal dezelfde volledige meergebruikerstoestand. Dus een script of instructie die zegt "start op naar runlevel 3 voor geen grafische omgeving" klopt op Red Hat en doet niets nuttigs op Debian. Alleen 0 (halt), 1 (enkelgebruiker) en 6 (herstart) betekenen overal hetzelfde.

7.3 init houdt echt op een ding toezicht: getty

Mensen zeggen dat oud init "geen toezicht op zijn diensten hield", en dat klopt grotendeels, met een duidelijke uitzondering: de respawn-actie in inittab. Elke regel gemarkeerd met respawn wordt door init opnieuw gestart op het moment dat hij stopt. Het belangrijkste gebruik is de getty-inlogprompts op de virtuele consoles: log uit, en init start meteen een verse prompt. Dit kleine stukje toezicht zat altijd al in init; systemd veralgemeende het simpelweg naar elke dienst met richtlijnen als Restart=on-failure.

7.4 Waarom het oude opstarten zo traag was

SysV init draaide de S-scripts in een runlevel strikt een voor een, in nummervolgorde, elk voltooid voordat het volgende begon. Als een netwerkkoppeling traag was, wachtte alles erachter simpelweg. Moderne hardware kan tientallen onafhankelijke diensten tegelijk starten, maar SysV init had geen idee welke diensten onafhankelijk waren, dus kon het ze niet veilig overlappen. Dit ene feit (serieel opstarten) is de duidelijkste reden dat een grote SysV-server minuten kon nemen om op te starten terwijl een gelijkwaardige systemd-machine seconden neemt: systemd leest de afhankelijkheden en start alles wat het veilig kan in parallel.

7.5 Op je systemd-machine is het allemaal een beleefde illusie

Draai service cron restart op een huidige Ubuntu- of Debian-machine en het werkt, met de melding "via systemctl". Er draait helemaal geen SysV init. systemd levert een generator die eventuele achtergebleven /etc/init.d-scripts bij het opstarten leest en elk daarvan ter plekke omzet in een tijdelijke unit, en het biedt vervangers voor service, telinit, runlevel, en zelfs een toewijzing van runlevels naar targets (runlevel 3 wordt multi-user.target). Het hele SysV-oppervlak wordt uit beleefdheid in leven gehouden zodat decennia aan scripts en gewoontes blijven werken.

7.6 Hoe de kernel init in de eerste plaats vindt

Voordat dit alles kan gebeuren, moet de kernel een init-programma vinden om als PID 1 te draaien, en dat doet het door een korte lijst met vaste paden op volgorde te proberen. De eerste die bestaat en draait, wint:

1. /sbin/init      the normal place (a symlink to systemd today)
2. /etc/init        an older location, tried next
3. /bin/init        another fallback
4. /bin/sh          last resort: just give a shell

Als geen ervan gedraaid kan worden, geeft de kernel het op met een paniek, omdat een systeem zonder PID 1 niet verder kan. Deze lijst is ook waarom een kapotte init te herstellen is. Je kunt de kernel vertellen hem helemaal over te slaan door een init=-optie toe te voegen aan de opstartregel in GRUB:

init=/bin/bash     boot straight into a shell as PID 1, no init at all

Deze klassieke reddingstruc geeft je een root-shell voordat welke dienst of zelfs het echte init start, wat precies is wat je wilt wanneer een verkeerde configuratie de machine normaal laat opstarten belet. Het werkt op elk Linux-systeem, SysV of systemd, omdat de keuze in de kernel gebeurt, een stap voordat init draait.

9. Veelgemaakte fouten

9.1 Mythe versus werkelijkheid

9.2 Andere valkuilen om te vermijden

• rcN.d-links met de hand bewerken. Het is makkelijk om de volgorde te breken of de bijbehorende K-link te vergeten. Gebruik in plaats daarvan update-rc.d of chkconfig.
• Een verouderd PID-bestand vertrouwen. Als een daemon sterft zonder op te ruimen, hoort het oude PID nu misschien bij een ander programma, en kan een stop het verkeerde proces doden.
• De LSB-kop vergeten op een nieuw script. Zonder deze kan het inschakelgereedschap de dienst niet correct in de opstartvolgorde plaatsen.
• Aannemen dat init 0 een veilige test is. Het halt de machine. Op een server op afstand betekent dat dat je hem net hebt uitgeschakeld zonder een makkelijke weg terug.
• Logboeken in de journal verwachten. Een pure SysV-dienst schrijft waarheen zijn script de uitvoer stuurt, vaak een bestand in /var/log of nergens; er is geen verenigde journal om te doorzoeken.
• Een init-script bewerken dat systemd door een eigen unit heeft vervangen. Als er een echte .service bestaat, gebruikt systemd die en negeert het oude /etc/init.d-script, dus je bewerkingen lijken niets te doen.