Server start niet meer op
Een server die niet meer opkomt, is precies het moment waarop paniek slecht werk oplevert. Bijna altijd is het een van een handvol oorzaken, en bijna altijd is de data nog intact. Belangrijk is dat je in de juiste volgorde werkt en niets overhaast overschrijft.
Loop je hier nu tegenaan?
Bel en leg het voor. Vaak is in tien minuten duidelijk waar het aan ligt. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Herken je dit?
- Na een reboot komt de machine niet meer online.
- Na een kernel- of systeemupdate blijft hij hangen tijdens het booten.
- De console toont een emergency shell of vraagt om het rootwachtwoord.
- Er staat een foutmelding over een filesystem of over fstab.
- De machine boot wel, maar diensten starten niet.
Waar het meestal aan ligt
In verreweg de meeste gevallen is het één van deze. Loop ze in deze volgorde na.
Een regel in fstab die niet klopt
Een verwijderde of hernoemde schijf, een UUID die is gewijzigd of een netwerkmount zonder nofail: dan stopt de boot en beland je in de emergency shell. Een van de meest voorkomende oorzaken.
Nieuwe kernel die niet werkt
Na een update start de nieuwe kernel niet, bijvoorbeeld door een ontbrekende module of een initramfs die niet correct is gebouwd. De vorige kernel staat vrijwel altijd nog in het bootmenu.
Volle schijf of volle boot-partitie
Een volle /boot zorgt ervoor dat een nieuwe kernel of initramfs onvolledig is weggeschreven. Dat merk je pas bij de volgende herstart, wat het verband vertroebelt.
Filesystem dat een controle nodig heeft
Na een harde stroomstoring kan een filesystem in een staat komen waarin het read-only wordt gemount of een fsck vraagt. Meestal herstelbaar, maar niet zonder nadenken.
Bootloader of EFI-configuratie
Een GRUB-installatie die na een schijfwissel naar het verkeerde device wijst, of een EFI-entry die is verdwenen. De machine komt dan niet eens tot de kernel.
Diensten die de boot ophouden
Een systemd-unit die op het netwerk of een mount wacht die er niet komt, kan het opstarten minuten of oneindig ophouden. systemd-analyze blame wijst dat na herstel aan.
Wat ik als eerste check
Doe deze stappen zelf, of bel en dan lopen we ze samen door.
- 1
Zorg eerst voor console-toegang
KVM, IPMI, een cloudconsole of een rescue-omgeving. Zonder te kunnen zien wat er op het scherm staat, ben je aan het gokken; de foutmelding op de console is je diagnose.
- 2
Maak een snapshot of image voordat je iets repareert
Bij twijfel eerst een kopie van de schijf. Herstelpogingen kunnen onbedoeld overschrijven, en één snapshot is het verschil tussen een vervelende middag en dataverlies.
- 3
Boot de vorige kernel
Kies in het GRUB-menu onder de geavanceerde opties de vorige kernel. Werkt dat, dan heb je je oorzaak en kun je in een werkend systeem de nieuwe kernel of initramfs repareren.
- 4
Kijk naar fstab in de emergency shell
cat /etc/fstabenblkidnaast elkaar: kloppen de UUID's nog? Zet netwerkmounts en niet-essentiële schijven opnofailzodat een boot hier nooit meer op vastloopt. - 5
Controleer schijfruimte
df -hendf -i, ook voor/boot. Een volle boot-partitie is een klassieke oorzaak na maanden kernelupdates zonder opruimen. - 6
Lees de logs van de mislukte boot
Na herstel:
journalctl -b -1 -p errlaat zien wat de vorige boot deed struikelen. Dat is het verschil tussen "hij doet het weer" en weten wat er was.
Rustig en in de juiste volgorde
Bij een machine die niet boot, is de volgorde belangrijker dan de snelheid. Eerst zien wat er op de console staat. Dan, als het even kan, een kopie of snapshot. Dan proberen te booten met de vorige kernel of via een rescue-omgeving. Pas daarna repareren.
Die volgorde voorkomt de scenario’s waar het echt vervelend wordt: een herinstallatie over een schijf die nog perfect intact was, of een mkfs op de verkeerde partitie omdat iemand onder druk aan het typen ging.
Nu een server plat?
Bel. Als er console- of rescue-toegang is, kan ik meestal direct meekijken. En zo niet, dan is de eerste stap die toegang regelen — ook daarbij kan ik je door de opties bij jouw hoster loodsen.
Veelgestelde vragen
- Ben ik mijn data kwijt?
- Vrijwel nooit. In de overgrote meerderheid van de gevallen is het een bootprobleem en staat de data ongeschonden op de schijf. Daarom is de eerste regel: niets overhaast herinstalleren of formatteren, en eerst een kopie maken als dat kan.
- Wat is rescue mode?
- Een omgeving waarin je van een ander medium of netwerkimage boot, je eigen schijf mount en van daaruit repareert. Elke serieuze hoster biedt die, en elke virtualisatieomgeving heeft een variant. Het is de standaardweg naar binnen bij een machine die niet boot.
- Kun je dit op afstand doen?
- Ja, zolang er console- of rescue-toegang is. Dat is bij vrijwel elke hoster en elk hypervisor-platform het geval. Heb je alleen SSH en komt de machine niet op, dan moet die toegang eerst geregeld worden.
- Hoe voorkom ik dit een volgende keer?
- Netwerkmounts op nofail, /boot opruimen bij updates, na een kernelupdate op een gepland moment herstarten in plaats van maanden later, en een snapshot vóór onderhoud. Dat zijn kleine ingrepen die dit type storing grotendeels wegnemen.
Verwante problemen
502 Bad Gateway bij nginx oplossen
502 Bad Gateway betekent dat nginx je applicatie niet kan bereiken of geen geldig antwoord krijgt. Dit zijn de oorzaken en de eerste checks.
[Docker]Docker-container start niet of crasht direct
Container die direct stopt, exit code 137 of 125, volumes die leeg zijn na een herstart en containers die elkaar niet vinden. Dit check ik als eerste.
[MySQL-replicatie]MySQL-replicatie is gestopt of loopt achter
Replicatie gestopt met een foutmelding, of een slave die steeds verder achterloopt. Meestal te repareren zonder volledige rebuild. Dit check ik als eerste.
Zelf geen tijd of geen zin om te blijven zoeken?
Ik kijk mee, zeg eerlijk wat er aan de hand is en los het op. Bellen mag direct. Mail beantwoord ik meestal dezelfde werkdag.
Terug naar Linux serverbeheer en troubleshooting