Kleine Linux-gewoonten die uren kunnen besparen als er iets misgaat

Het beheren van Linux gaat niet alleen over het onthouden van commando’s. Veel verschillen tussen het oplossen van een probleem in tien minuten of het besteden van een uur aan experimenteren, zitten in kleine gewoonten: eerst kijken voordat je iets doet, controleren wat er veranderd is, bewijzen bewaren voordat je herstart, en de uitkomst van elke actie verifiëren. Het zijn eenvoudige praktijken die zowel voor iemand die een thuisserver onderhoudt als voor teams die verantwoordelijk zijn voor productieomgevingen, waardevol zijn.

De sleutels tot goede gewoonten in Linux in 20 seconden

• Voordat je een service herstart, is het verstandig om de status te controleren en de laatste logs te bekijken.
• journalctl, ss, findmnt of vmstat helpen om echt te begrijpen wat er aan de hand is.
• Destructieve commando’s moeten eerst uitgeprobeerd worden met opties zoals --dry-run.
• Automatisering vereist foutcontrole en mag niet afhankelijk zijn van de omgeving van de terminal.
• Het documenteren van incidenten voorkomt dat je hetzelfde probleem twee keer moet onderzoeken.

Je hoeft geen observatieplatform te installeren om deze praktijken toe te passen. Veel benodigde tools maken deel uit van elke moderne distributie.

Het kernidee is het wijzigen van een zeer menselijke gewoonte: stop met proberen oplossingen te vinden voordat je het probleem hebt begrepen.

Voordat je Linux repareert, moet je eerst vragen wat er aan de hand is

Wanneer een website niet reageert, een database lijkt te hangen of een service uitvalt, lijkt het herstarten meestal de snelste oplossing.

Bijvoorbeeld:

systemctl restart nginx

Dit werkt soms.

Het probleem is dat hiermee ook de systeemstatus verandert en nuttige informatie kan verdwijnen die helpt te begrijpen wat er precies is gebeurd.

Voor het herstarten is het veel interessanter om eerst te executeer:

systemctl status nginx

Daarna kunnen recente berichten worden bekeken:

journalctl -u nginx --since "-15 min"

En verifiëren of er daadwerkelijk een proces luistert op de verwachte poorten:

ss -lntp

Een extra blik op opslag en geheugen geeft een eerste overzicht:

df -h

free -h

Met minder dan een minuut heb je al vrij veel informatie verzameld.

Deze werkwijze introduceert een eenvoudige regel: eerst observeren, dan ingrijpen.

Vragen wat er is veranderd, bespaart vaak veel tijd

Een server die gisteren nog werkte en vandaag niet, is zelden door magie veranderd.

Er kan een update, deployment, certificaatwijziging, configuratiewijziging of firewallregel zijn geweest.

Daarom is het zinvol om te beginnen met:

git status

git diff

Als configuratie onder versiebeheer staat, kunnen ook recentelijk gecommitte wijzigingen worden gecontroleerd:

git log --since="2 dagen geleden" --oneline

Op Debian- of Ubuntu-servers kunnen ook de APT- en dpkg-logs worden geraadpleegd; voor RPM-gebaseerde distributies bestaan vergelijkbare historials.

In professionele omgevingen kunnen ook deployment-logs van CI/CD, Ansible of andere automatiseringsplatforms nog revelerender zijn.

Vragen “Wat is er veranderd?” is vaak een betere strategie dan meteen te zoeken naar een complexe oorzaak.

journalctl wordt veel bruikbaarder wanneer je het filtert

Een veel voorkomende fout is het uitvoeren van:

journalctl -xe

en dan geconfronteerd worden met honderden of duizend regels.

Het probleem kan daar zitten, maar ver weg verborgen.

Het is veel efficiënter om te beperken wat je zoekt.

Alleen de logs van nginx:

journalctl -u nginx

De laatste twintig minuten:

journalctl -u nginx --since "-20 min"

Fouten sinds de huidige opstart:

journalctl -p err -b

Kernelmeldingen:

journalctl -k -b

En er is een speciale optie als een server net is herstart:

journalctl -b -1

Hiermee kan je het vorige opstartproces bekijken, waardoor je kunt onderzoeken wat er gebeurde vóórdat het systeem opnieuw werd opgestart.

Het controleren van mislukte services kost slechts enkele seconden

Een ander klein commando dat problemen kan onthullen, is:

systemctl --failed

Dit toont systemd-eenheden die in de failed-status verkeren.

Het kan gaan om een hulpdienst, een mount, een opstarttaak of een component dat nog geen zichtbaar falen vertoont.

Het is verstandig om dat eerst te bekijken voordat je het reset met:

systemctl reset-failed

Ook hier geldt: voorkom dat je een aanwijzing wegbrandt zonder te begrijpen wat die betekent.

Netwerk, disks en prestatie: echt kijken wat er gebeurt

De configuratie van een applicatie bepaalt hoe het zou moeten functioneren.

Linux kan laten zien hoe het zich daadwerkelijk gedraagt.

Het verschil is belangrijk.

ss bevestigt welke poorten luisteren

Als een applicatie bijvoorbeeld op poort 443 zou moeten werken, kan je controleren met:

ss -lntp

Dit commando toont TCP-sockets in luisterpositie, en met voldoende rechten ook de bijbehorende processen.

Voor UDP:

ss -lunp

En voor actieve TCP-verbindingen:

ss -tnp

Hierdoor kunnen verschillende problemen snel worden opgespoord.

Als er niets te zien is op :443, luistert de service waarschijnlijk niet.

Wanneer er wel iets staat zoals:

127.0.0.1:443

maar het zou toegankelijk moeten zijn vanaf een andere machine, dan is het mogelijk dat de service enkel op localhost is gebonden.

Controleer altijd eerst het lokale systeem alvorens te zoeken bij routers, firewalls of cloudproviders.

df vertelt niet het volledige verhaal over opslag

Vrijwel elke admin kent:

df -h

Dat geeft snel inzicht in gebruikte ruimte.

Maar moderne systemen kunnen meerdere partities, LVM-volumes, clouddiscs, NFS, bind mounts of containeropslag bevatten.

Voor het bekijken van apparaten:

lsblk

Voor het inspecteren van mountpoints:

findmnt

En om concreet te achterhalen waar bijvoorbeeld /var/lib/docker zich bevindt:

findmnt --target /var/lib/docker

Deze combinatie helpt om te onderscheiden tussen fysieke disk, partitie, bestandssysteem en mountpunt, concepten die verwant zijn, maar niet gelijk.

Ook voorkomen ze gevaarlijke fouten bij meerdere disks met vergelijkbare namen.

Een momentopname van CPU vertelt niet altijd het hele verhaal

top toont wat er nu gebeurt.

Maar een machine kan problemen vertonen die slechts tijdens korte periodes van enkele seconden per minuut zichtbaar zijn.

Daarvoor zijn tools zoals:

vmstat 1

Elk tweede geeft informatie over CPU, geheugen, processen, swap en I/O-activiteit.

Als sysstat geïnstalleerd is, is ook iostat -xz 1 zeer nuttig.

Hierdoor wordt de opslagactiviteit gedetailleerder zichtbaar.

Het verschil is dat top vertelt wat er op dit moment gebeurt, terwijl een reeks metingen patronen kan tonen die tot de root van het probleem leiden.

Wanneer de applicatie niet de oorzaak is, kijk dan naar de kernel

Soms geven services enkel door dat er een probleem is, zonder de oorzaak te verklaren.

De kernel kan hier de ontbrekende schakel bieden:

journalctl -k -b

Hiermee kunnen problemen met disks, geheugen, drivers of netwerkinterfaces worden opgespoord.

Als een proces zonder duidelijke reden verdwijnt, is het ook goed om signalen te zoeken die verband houden met geheugendruk en de OOM-killer.

Een probleem dat lijkt te komen door een applicatie, kan eigenlijk door het besturingssysteem worden veroorzaakt.

De beste gewoonten worden gevormd vóór het indrukken van Enter

Linux maakt het mogelijk om met één regel veel te doen.

Dat is een voordeel, maar ook een risico.

Bijvoorbeeld:

find /backup -type f -mtime +30 -delete

verlies je direct alle bestanden die voldoen aan die criteria.

Eerst kun je de selectie zonder te verwijderen testen:

find /backup -type f -mtime +30 -print

Als de output correct is, voeg je -delete toe.

Hetzelfde geldt voor rsync.

Voor je het commando daadwerkelijk uitvoert, is het verstandig om:

rsync -a --delete --dry-run /source/ /destination/

--dry-run toont wat er zou gebeuren zonder dat er daadwerkelijk iets verandert.

Deze gewoonte kan grote dataverliezen voorkomen.

De configuratie valideren vóór herstart

Stel dat je nginx wijzigt.

In plaats van direct te editen en te herstarten, kun je eerst testen:

nginx -t

Alleen als de test slaagt, herlaad je de configuratie met:

systemctl reload nginx

Een goede werkwijze is dan:

bewerk
valideer
vergelijk
herlaad
controleer

In plaats van:

bewerk
herstart
wacht

Bovendien is het, indien een service het ondersteunt, vaak beter om reload te gebruiken dan een volledige herstart.

kill -9 is het laatste redmiddel

Wanneer een proces vast lijkt te zitten, lijkt het verleidelijk om direct te gebruiken:

kill -9 PID

Maar SIGKILL stopt het proces onmiddellijk zonder dat het nog kan opruimen.

Meestal is het beter eerst te proberen met:

kill PID

Wat een SIGTERM signaleert.

En vooraf kun je controleren welk proces je probeert te beïnvloeden:

ps -fp PID

Ook kun je meer informatie opvragen:

cat /proc/PID/status

Soms is kill -9 echt noodzakelijk.

Het is echter altijd een goede gewoonte om deze laatste optie te bewaren voor noodgevallen.

Goed automatiseren is meer dan alleen een script schrijven

Veel scripts werken prima wanneer je ze handmatig uitvoert, maar falen in cron of systemd.

De oorzaak ligt vaak in de omgeving.

Een interactieve terminal heeft vaak een PATH, variabelen, SSH-sleutels of een werkmap die niet beschikbaar is in geautomatiseerde processen.

In plaats van:

python backup.py

kun je beter gebruiken:

/usr/bin/python3 /opt/scripts/backup.py

Het is ook verstandig om de benodigde omgeving expliciet te definiëren en niet afhankelijk te zijn van persoonlijke aliases.

Controleren of een commando geslaagd is

Bash gebruikt exit-codes.

Na een commando kun je controleren met:

echo $?

Een waarde van 0 betekent meestal succes.

In scripts is het beter om de operatie direct te controleren:

if rsync -a /data/ /backup/data/; then
    echo "Backup voltooid"
else
    echo "Backup mislukt" && exit 1
fi

Zo wordt het resultaat onderdeel van de logica zelf. Een backup is pas geslaagd als het script dat aangeeft.

set -e maakt scripts niet automatisch compleet foutbestendig

Het is gangbaar om set -e te gebruiken, waarmee het script stopt bij bepaalde fouten.

Het kan handig zijn, maar Bash kent meerdere uitzonderingen op dit gedrag.

Een veelgebruikte combinatie is:

set -Eeuo pipefail

pipefail is vooral interessant voor pijplijnen.

Bijvoorbeeld:

grep "error" niet-bestaand-bestand | sort

Zonder pipefail levert dat mogelijk toch resultaten op van sort, ook al faalde grep.

Niets vervangt echter een expliciete foutafhandeling in belangrijke automatiseringen.

Automatisering van controles kan beter zijn dan automatisering van herstel

Niet elke automatisering moet meteen ingrijpen.

Soms is het beter om alleen te waarschuwen.

Bijvoorbeeld:

systemctl is-active --quiet nginx || echo "nginx is niet actief"

Vervolgens kunnen automatisch controles worden gedaan op:

• vrije ruimte;
• recente backups;
• verlopen certificaten;
• verplichte mountpoints;
• mislukte services;
• luisterende poorten;
• RAID-status;
• navigatietijd.

Automatisch herstarten telkens wanneer een probleem wordt gevonden, kan jarenlang een incident verbergen.

Het vastleggen van de situatie maakt het mogelijk de oorzaak te onderzoeken.

Een snapshot maken van het systeem voordat je het aanpakt

Een diagnostisch script kan in enkele seconden basisinformatie verzamelen:

date
hostname
uptime
free -h
df -h
lsblk
systemctl --failed
ss -lntp
journalctl -p err -b --no-pager

En deze bewaren:

/opt/tools/capture-state.sh > "/var/tmp/state-$(date +%Y%m%d-%H%M%S).log" 2>&1

Als later herstarten nodig is, blijft er een snapshot van de vorige situatie bewaard, wat heel waardevol kan zijn bij complexe incidenten.

Het niet-terminale habit: documenteer wat je leert

Elk opgelost probleem kan leiden tot herbruikbare kennis.

Een eenvoudige registratie zou moeten omvatten:

• wat er gebeurde;
• wanneer het begon;
• wat er is veranderd;
• welke logs zijn gecontroleerd;
• welke commando’s hielpen;
• wat de oorzaak was;
• hoe het opgelost is;
• hoe het in de toekomst eerder kan worden ondervonden.

Een platform is niet noodzakelijk. Een privé Git-repository met Markdown-documenten kan in de loop van de tijd uitgroeien tot een kleine kennisbank over de echte problemen binnen de infrastructuur.

En het belangrijkste voordeel: zes maanden later hoeft niemand meer precies dezelfde oplossing opnieuw te ontdekken.

De ervaring van een goede administrator zit niet enkel in het geheugen, maar ook in de procedures die hij schriftelijk heeft vastgelegd.

Linux beloont meer het methodisch werken dan snelheid

Twee personen kennen dezelfde commando’s, maar werken anders:

De eerste:

herstart
testen
iets veranderen
weer testen

De tweede:

observeren
bewijzen bewaren
begrenzen
hypothese formuleren
verifiëren
minimaal aanpassen
controleren

De tweede werkt niet per se meer Linux, maar met een betere methode.

Deze systematische aanpak blijft waardevol, zelfs met tools als Prometheus, Grafana, OpenTelemetry, Kubernetes of andere complexe observatieplatforms.

Wanneer iets misgaat, moeten altijd vragen worden gesteld zoals: Welke processen zijn actief? Welke poorten luisteren? Wat heeft er veranderd? Welke disk is vol? Of wat heeft de kernel geschreven voordat het allemaal begon te mislukken?

Deze vragen worden beantwoord met behulp van commando’s die je vaker moet leren gebruiken.

Goed gedrag bepaalt of je de juiste vragen stelt vóór je het systeem aanpast.

Veelgestelde vragen

Wat moet ik eerst controleren als een Linux-server niet werkt?

Afhankelijk van het probleem, maar het raadplegen van systemctl status, journalctl, systemctl --failed, ss, df, free en findmnt geeft snel een eerste overzicht van de systeemstatus.

Waarom is het niet verstandig om direct een service opnieuw te starten?

Omdat herstarten de systeemstatus kan veranderen en nieuwe logs creëert, waardoor het moeilijk wordt te achterhalen wat de oorzaak was. Eerst bewijs verzamelen is beter.

Waarvoor dient --dry-run?

Geeft de mogelijkheid om bewerkingen te simuleren zonder ze echt uit te voeren. Tools zoals rsync tonen daarmee welke bestanden gekopieerd of verwijderd zouden worden.

Is set -e voldoende om bash-scripts veilig te maken?

Nee. Het helpt wel om scripts te stoppen bij sommige fouten, maar heeft uitzonderingen. In belangrijke automatiseringen is het beter om resultaten expliciet te controleren en opties zoals pipefail te begrijpen.

Bronnen:

• Officiële documentatie van systemd: systemctl, journalctl en systemd-analyze.
• GNU Bash Reference Manual.
• Project util-linux: documentatie van lsblk en findmnt.
• iproute2: documentatie van ss.
• procps-ng en sysstat: diagnose- en prestatietools.