Linux troubleshooten in 4 stappen: zo vind je de oorzaak van bijna elke fout

Waarom je een stappenplan nodig hebt bij Linux problemen oplossen

Wie een Linux-foutmelding krijgt, zoekt meestal meteen naar de letterlijke tekst en probeert het eerste commando dat op een forum staat. Soms werkt dat. Vaker verlies je er een uur mee, of erger: je verandert iets dat de oorzaak verhult.

Een vast stappenplan lost dat op. Het dwingt je om eerst te begrijpen wat er stuk is voordat je nadenkt over hoe je het repareert. Dat is precies hoe ervaren beheerders werken, ook als ze een systeem al jaren kennen.

De vier stappen die we in dit artikel uitwerken:

1. Verzamelen: wat is er precies aan de hand en sinds wanneer?
2. Logs lezen: wat zegt het systeem zelf?
3. Hypothese testen: wat is de meest waarschijnlijke oorzaak, en hoe bewijs je dat?
4. Documenteren: wat heb je gevonden en hoe voorkom je herhaling?

Stap 1: Verzamel feiten voordat je iets aanpast

De belangrijkste regel van linux troubleshooten: wijzig niets zolang je niet weet wat er aan de hand is. Begin met vijf vragen.

• Wat is de exacte foutmelding? Kopieer hem letterlijk, inclusief foutcode.
• Sinds wanneer treedt het probleem op, en is het constant of af en toe?
• Wat is er recent veranderd? Denk aan updates, nieuwe configuratie, een nieuwe gebruiker of een certificaat dat verliep.
• Wie of wat is getroffen: alle gebruikers, één applicatie, één server?
• Kun je het probleem reproduceren?

Een groot deel van de storingen heeft een oorzaak die vlak voor het eerste symptoom is ontstaan. Een apt upgrade van gisteren of een aangepaste config van vanochtend is daarom altijd je eerste verdachte.

De gezondheidscheck in 60 seconden

Voer daarna een korte basiscontrole uit. Deze commando's kosten bijna niets en geven een goed beeld:

uptime                # belasting en hoe lang de server draait
free -h               # geheugen en swap
df -h                 # schijfruimte per bestandssysteem
df -i                 # inodes (kan vol zijn terwijl df -h er prima uitziet)
systemctl --failed    # services die niet gestart zijn
ss -tlnp              # welke processen luisteren op welke poort

Let op afwijkingen. Een load average die ver boven het aantal CPU-kernen ligt, een bestandssysteem op 100% of een lijst met mislukte services wijst je meteen de richting.

Stap 2: Linux logs bekijken en journalctl gebruiken

Als je de feiten op een rij hebt, laat je het systeem zelf vertellen wat er misging. Op vrijwel alle moderne distributies (Ubuntu, Debian, RHEL, Rocky, Fedora) draait systemd, en dus is journalctl je belangrijkste gereedschap om linux logs te bekijken.

Journalctl gebruiken: de belangrijkste opties

journalctl -xe                          # laatste meldingen, met uitleg
journalctl -u nginx                     # alleen logs van de nginx-service
journalctl -u nginx --since "1 hour ago"
journalctl -p err -b                    # alleen fouten sinds de laatste boot
journalctl -f                           # live meekijken (zoals tail -f)
journalctl -k                           # kernelmeldingen
journalctl -b -1                        # de vorige boot, handig na een crash
journalctl --disk-usage                 # hoeveel ruimte de journal inneemt

Combineer opties gerust. journalctl -u nginx -p err --since today toont bijvoorbeeld alleen de nginx-fouten van vandaag. Dat is vaak genoeg om de oorzaak te vinden.

Welke logbestanden zijn het belangrijkst?

Naast de journal bestaan er nog klassieke tekstlogs in /var/log. Welke je nodig hebt, hangt af van het probleem:

Zoek je in een groot logbestand? Gebruik grep -i error of grep -i "failed", en kijk naar de regels vlak voor de eerste fout. De echte oorzaak staat vaak een paar regels eerder dan de foutmelding waar je mee begon.

Stap 3: Formuleer een hypothese en test één ding tegelijk

Nu je feiten en logregels hebt, formuleer je een hypothese. Een goede hypothese is concreet en toetsbaar: "nginx start niet omdat poort 80 al bezet is", niet "er is iets mis met de webserver".

Houd je daarbij aan drie spelregels:

1. Eén wijziging per keer. Pas je twee dingen tegelijk aan en het werkt, dan weet je niet welke de oplossing was.
2. Test eerst zonder te wijzigen. Veel hypotheses kun je controleren met een leescommando, zoals ss -tlnp | grep :80.
3. Maak een back-up van wat je aanpast. Kopieer een configbestand voordat je het bewerkt: cp nginx.conf nginx.conf.bak.

Werkt je hypothese niet? Dat is nuttige informatie. Streep hem door, noteer het, en ga terug naar de logs voor de volgende kandidaat. Dat is geen falen, maar de methode.

Stap 4: Documenteer wat je vond

Deze stap wordt het vaakst overgeslagen en is toch degene die je het meest oplevert. Zes maanden later heb je dezelfde fout opnieuw, en je weet niet meer wat de oplossing was.

Schrijf na elk incident kort op:

• Het symptoom en het tijdstip
• De oorzaak (de echte, niet het symptoom)
• Welke commando's of wijzigingen de oplossing brachten
• Wat je doet om herhaling te voorkomen, bijvoorbeeld monitoring op schijfruimte

Een simpel tekstbestand in een gedeelde map of wiki is genoeg. Het gaat erom dat de kennis niet alleen in je hoofd zit.

Drie praktijkvoorbeelden van Linux foutmelding oplossen

Voorbeeld 1: nginx start niet meer na een configwijziging

Symptoom: systemctl restart nginx geeft "Job for nginx.service failed".

systemctl status nginx
journalctl -u nginx -n 30 --no-pager
nginx -t

Het commando nginx -t test de configuratie en noemt het bestand en het regelnummer van de fout. Meestal is het een ontbrekende puntkomma of een verwijzing naar een certificaat dat niet bestaat. Krijg je "address already in use"? Dan houdt een ander proces de poort bezet:

ss -tlnp | grep ':80'

Zo zie je welk proces dat is, en kun je beslissen of je dat stopt of nginx op een andere poort zet.

Voorbeeld 2: een service crasht steeds opnieuw

Symptoom: je applicatie draait een paar minuten en stopt dan zonder duidelijke reden.

systemctl status mijnapp
journalctl -u mijnapp --since "2 hours ago" -p warning
journalctl -k | grep -i "out of memory"

Zie je in de kernellog "Out of memory: Killed process", dan is de kernel de boosdoener: het geheugen was op en de OOM-killer heeft je proces afgeschoten. De oplossing zit dan in geheugengebruik (een lek, te veel workers) en niet in de service zelf. Dit is een goed voorbeeld van waarom je kijkt naar wat het systeem zegt, en niet alleen naar de applicatie.

Voorbeeld 3: de schijf is vol (of lijkt vol)

Symptoom: "No space left on device", terwijl je zeker weet dat er ruimte moet zijn.

df -h                                   # welke partitie is vol?
df -i                                   # zijn de inodes op?
du -xh --max-depth=1 /var | sort -h     # welke map is het grootst?
journalctl --disk-usage
lsof +L1                                # verwijderde bestanden die nog open staan

Drie veelvoorkomende oorzaken: logbestanden die nooit geroteerd worden, miljoenen kleine bestanden die alle inodes opmaken (zichtbaar in df -i), of een verwijderd logbestand dat nog door een draaiend proces wordt vastgehouden. In dat laatste geval komt de ruimte pas vrij als je het proces herstart.

Cheatsheet: commando's om een Linux-server te diagnosticeren

Je hoeft dit niet uit je hoofd te leren. Het gaat erom dat je weet welke vraag bij welk commando hoort.

Veelgemaakte fouten bij linux troubleshooten

• Direct herstarten. Een reboot wist vaak precies het bewijs (geheugen, lopende processen) dat je nodig had. Verzamel eerst, herstart daarna.
• Blind chmod 777 uitvoeren. Het lost een rechtenprobleem op, maar creëert een beveiligingsprobleem. Zoek uit welke gebruiker toegang nodig heeft en geef alleen dat.
• Commando's van het internet plakken zonder ze te begrijpen. Lees eerst wat een commando doet, vooral bij rm, dd en alles met sudo.
• Alleen naar het symptoom kijken. Een volle schijf is het symptoom, de logrotatie die ontbreekt is de oorzaak.
• Geen eerste back-up. Op een productieserver zonder recente back-up is voorzichtig werken geen luxe.

Wanneer schakel je hulp in?

Zelf troubleshooten is een prima aanpak voor de meeste storingen. Er zijn alleen situaties waarin doorzoeken meer kost dan het oplevert:

• Er staat productiedata of omzet op het spel en elke minuut downtime kost geld.
• Je vermoedt dat de server is aangevallen of gecompromitteerd (onbekende gebruikers, vreemde processen, ongebruikelijke uitgaande verbindingen).
• Je hebt na een uur systematisch zoeken nog geen werkende hypothese.
• Het gaat om een database, RAID of bestandssysteem waar een verkeerde handeling dataverlies kan veroorzaken.

In die gevallen loont het om een ervaren collega of externe specialist mee te laten kijken. Bij LinuxHulp.nl doen we dit dagelijks: bekijk onze diensten voor Linux-beheer en spoedhulp of de tarieven om te zien wat bij je situatie past. Wil je vooraf weten hoe dat werkt, lees dan ook de veelgestelde vragen.

Samenvatting

Linux problemen oplossen gaat het snelst als je methodisch werkt: verzamel feiten, lees de logs met journalctl, test één hypothese tegelijk en leg vast wat je leerde. Het is geen kwestie van meer commando's kennen, maar van de juiste vragen stellen in de juiste volgorde.

Print de cheatsheet hierboven gerust uit of bewaar hem in je eigen notities. De volgende keer dat een foutmelding oplicht, weet je precies waar je begint.