Wanneer een Linux-server niet meer reageert, staat het eerste commando niet altijd op de server

Wanneer een Linux-server niet meer reageert, is de verleiding vaak groot om via SSH in te loggen en commando’s uit te voeren. top, free, df, systemctl, journalctl. Allemaal nuttige tools, maar ze zouden niet altijd de eerste stap moeten zijn. Voordat je de CPU, het geheugen of de schijf diagnoseert, is het verstandig een meer basale vraag te beantwoorden: is de server echt uit de lucht of is deze slechts niet bereikbaar via een bepaalde route?

Daarom, in een echt incident, is het eerste commando meestal niet iets dat binnen de server wordt uitgevoerd. Het kan zo simpel zijn als:

ping -c 4 

Of, als je iets iets nuttigers wilt om tussenliggende hops te zien:

mtr 

De reden is simpel. Als er geen connectiviteit is, verandert alles. Het besturingssysteem kan nog functioneren, maar er is een netwerkprobleem, een firewall, routingprobleem, switch, VPN, load balancer, cloudprovider of beveiligingsregel. Als je meteen via SSH probeert te verbinden en die reageert niet, kan je ten onrechte denken: “De server ligt eruit.” Soms is dat niet zo. Het is alleen geïsoleerd geraakt.

Een goed systeemdiagnose begint met het uitsplitsen van symptomen. Het is niet hetzelfde dat een website niet laadt, dat poort 22 niet reageert, dat er geen ICMP-pakketten doorkomen, dat de server vaststaat, dat de kernel nog leeft maar er geen nuttige processen draaien, of dat de schijf 100% vol is en logs niet meer geschreven kunnen worden.

Eerst, controleren of er een weg naar de machine is

De eerste minuut van een incident moet dienen om de reikwijdte te bevestigen. Is één server uit de lucht, of meerdere? Een service of de hele machine? Vanuit één locatie of vanaf elk netwerk? Zijn er gebruikers getroffen of alleen bepaalde monitoring?

Een logische aanpak start met connectiviteit:

ping -c 4 

Vervolgens route:

mtr 

En als de server reageert op het netwerk, test dan de getroffen dienst:

curl -I https://domein.com
nc -vz  22
nc -vz  443

Dit geeft inzicht in of het probleem zich op het netwerk, poort, dienst of tussenlaag bevindt. Als ping reageert, maar SSH niet, betekent dat niet noodzakelijk dat de server eruit ligt. Er kan een probleem zijn met sshd, een firewall, overbelasting van processen, verbindingslimieten of een te hoge belasting waardoor de sessie niet tot stand komt.

Reageert er helemaal niets, dan is de volgende stap niet blind herschrijven of herstarten. Controleer met een alternatieve console: KVM, iLO, iDRAC, IPMI, hypervisorconsole, cloudproviderconsole of seriële toegang indien beschikbaar. Herstarten kan het service herstellen, maar kan ook nuttige aanwijzingen verwijderen en van een diagnosticeerbaar incident een onoplosbare situatie maken.

Als SSH wel reageert, is de eerste nuttige opdracht uptime

Eenmaal ingelogd op de server, geeft de volgende opdracht vaak snel inzicht:

uptime

Het lost niets op, maar geeft richting. Het toont hoelang de machine al draait, hoeveel gebruikers er verbonden zijn en, vooral, de belasting (load average). Als de loadschalen hoog staan — bijvoorbeeld 80, 120 of zelfs 300 op een systeem met 4 vCPU — dan is de server mogelijk wel actief, maar praktisch onbruikbaar.

Vervolgens is het zinvol om processen te bekijken:

top -b -n 1 | head -20

Of direct per CPU:

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

En op geheugen:

free -h
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head

Zo wordt herkenbaar of het probleem zich richt op CPU, RAM, swap, lopende processen, geheugenlekken of een teveel aan geblokkeerde taken.

Een belangrijk detail: veel processen in de D-staat (onready) kunnen wijzen op problemen met schijf of opslag, in plaats van CPU. Het systeem lijkt dan te bevriezen omdat het wacht op I/O-operaties die niet afronden. Het zonder voldoende kennis processen killsen kan het probleem verergeren.

Disks, inodes en logs: drie klassiekers die servers blijven lamleggen

Veel Linux-incidenten worden veroorzaakt door minder glamouruze problemen: een volle schijf, een logs directory die uit de hand loopt, een slecht geplande backup, een applicatie die miljoenen kleine bestanden schrijft, een /var-partitie die vol is, of een volume zonder inodes ondanks dat er nog ruimte in GB is.

Daarom is het belangrijk de volgende commando’s altijd bij de hand te hebben:

df -h
df -i
du -xhd 1 / 2>/dev/null | sort -hr | head

df -h toont de oppervlakte op schijf. df -i toont inodes — een vaak over het hoofd geziene oorzaak. Als inodes op zijn, kan het systeem geen nieuwe bestanden meer maken, ondanks dat er nog schijfruimte is.

Daarnaast kunnen recente logs snel inzicht geven:

journalctl -xe --no-pager | tail -50
journalctl -p err --since "1 hour ago"
dmesg -T | tail -100

Hier kunnen kernelfouten, diskproblemen, OOM Killer, herstartende diensten, netwerkproblemen of I/O-meldingen verschijnen. Voordat je herstart, is het verstandig het log te bekijken, omdat een herstart het tijdelijke overzicht kan verwijderen en de oorzaak kan verbergen.

Mitigeren is niet hetzelfde als diagnosticeren

In een incident strijden twee doelen: snel het herstel van de service en het begrijpen van de oorzaak. Het evenwicht hangt af van de impact. Bij ernstige uitval wordt snel ingegrepen, maar zonder alle bewijzen te verwijderen.

Enkele gebruikelijke acties:

Een commando zoals dit kan nodig zijn:

kill -9 

Maar dit moet een weloverwogen beslissing zijn, geen reflex. kill -9 forceert het proces te stoppen zonder legitiem afsluiten. Soms is het onvermijdelijk; soms is het voldoende om een dienst opnieuw te starten of een wachtrij te onderbreken.

Hetzelfde geldt voor het herstarten van de server:

systemctl reboot --force

Dit moet het laatste redmiddel zijn. Als het systeem volledig vaststaat en er geen andere opties zijn, kan seriële console, SysRq of vergelijkbare hulpmiddelen nodig zijn, maar het is essentieel te weten wat je doet. Een snelle herstart mag geen dataverlies veroorzaken, dus moet zorgvuldig gebeuren.

Het incident eindigt niet met het herstellen van de service

Een van de duurste fouten in operationele terminologie is het incident sluiten zodra de website weer reageert. Dat is het einde van de uitval, niet het einde van het werk. Het is belangrijk te documenteren wat er is gebeurd, hoelang het duurde, welke impact er was, wat is gedaan, wat werkte en wat er veranderd moet worden om herhaling te voorkomen.

Een goede post-mortem zou de volgende vragen moeten beantwoorden:

De gouden regel is eenvoudig: raad niet omdat je het zeker weet. Observeer, meet en begrijp voordat je handelt. Een goede systeembeheerder is niet degene die het meeste commando’s uitvoert, maar degene die weet in welke volgorde en wanneer te stoppen om verdere schade te voorkomen.

Als je snel een kort antwoord op de eerste vraag moet geven, is dat dit: eerst controleer ik de connectiviteit met ping of mtr. Als SSH reageert, voer ik uptime uit. Het eerste scheidt netwerk van systeem. Het tweede geeft snel inzicht in belasting en algemene staat. Vanaf dat punt wordt de diagnose niet meer blind uitgevoerd.

Veelgestelde vragen

Wat is het eerste commando bij een niet-reagerende server?
Van buitenaf, ping -c 4 of mtr voor connectiviteitscontrole. Als SSH reageert, is uptime binnen de server meestal het eerste dat je kunt doen.

Waarom niet meteen top gebruiken?
Omdat je misschien helemaal geen toegang hebt tot de server. Het is eerst belangrijk te weten of het probleem bij het netwerk, de toegang, poorten, diensten of het hele systeem ligt.

Welke commando’s helpen bij het opsporen van een volle disk?
df -h voor de schijfruimte en df -i voor inodes. Beide zijn belangrijk, want een systeem kan zonder inodes zitten, ondanks dat er nog ruimte in GB is.

Welke logs moet ik in de eerste minuten bekijken?
journalctl -xe --no-pager, journalctl -p err --since "1 uur geleden" en dmesg -T | tail -100 geven vaak snel inzicht in recente fouten.

Wanneer moet ik een server herstarten?
Als alle andere mitigaties zijn uitgeput of het systeem niet meer te herstellen is. Herstarten zonder diagnose kan bewijzen weggooien en de oorzaak verhullen.