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 of mail en leg het voor. Neem ik niet op, stuur dan even een mail.
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 of een UUID die is gewijzigd: dan stopt de boot en beland je in de emergency shell. Een van de meest voorkomende oorzaken. Een netwerkmount die niet lukt geeft meestal geen shell, wel een lange wachttijd en services die niet starten.
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 de vorige kernel (op Debian en Ubuntu onder de geavanceerde opties; zie je geen menu, houd dan Shift of Esc ingedrukt). 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 opnofail, metx-systemd.device-timeout=10serbij, zodat een boot hier niet meer op blijft hangen. - 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 werkt alleen als de journal bewaard wordt (/var/log/journalbestaat). Anders is de vorige boot weg.
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 of mail. Met console- of rescue-toegang kan ik op afstand meekijken. Is die er 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, data die weg is na een update 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.
Wil je dit bespreken?
Bel of mail met je vraag. Neem ik niet op, stuur dan even een mail.
Terug naar Linux-serverbeheer en hosting