journalctl: logs onder systemd analyseren en permanent bewaren

Een server waarmee iets mis is, heeft meestal allang opgeschreven wat er gebeurd is. Het probleem is niet dat de informatie ontbreekt, maar de hoeveelheid waarin ze staat. Wie journalctl zonder argumenten aanroept, komt aan het begin van het journal terecht en bladert door meldingen van weken oud. Deze handleiding laat zien hoe u in drie of vier commando's precies het stuk uitsnijdt dat bij de storing hoort.

Het artikel systemd-service aanmaken behandelt de basisvormen -u, -b en -f. Hier gaat het om alles wat daarna komt: tijdvensters, filters, prioriteiten, uitvoerformaten, het permanent bewaren van het journal, groottelimieten, kernelmeldingen en kant-en-klare zoekpatronen.

Alle gegevens gelden voor Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS en Ubuntu 22.04 LTS. De commando's zijn geschreven voor gebruik als root. Werkt u als gewone gebruiker, zet dan voor elk commando sudo.

Voordat u iets wijzigt: de weg terug

Het journal lezen is ongevaarlijk, geen enkel zoekcommando in dit artikel verandert iets aan het systeem. Riskant zijn precies drie dingen, en die komen allemaal pas later.

Een vol bestandssysteem. Zonder eigen bovengrens gebruikt het journal tot tien procent van het bestandssysteem, met een plafond van vier gigabyte. Op een kleine schijf is een volle /var de korte weg naar een server die geen login meer accepteert.

Een typefout in de configuratie. systemd negeert onbekende sleutels in plaats van de dienst te stoppen. Uw limiet staat dan wel in het bestand, maar werkt niet, en niemand vertelt het u ongevraagd.

Te vroeg opruimen. journalctl --vacuum-time=1d verwijdert onherroepelijk, ook het bewijsmateriaal dat u juist zoekt.

De reddingsweg voor het ergste geval: KVM-rootservers en dedicated servers van KernelHost hebben geen IPMI en geen iDRAC. De toegang die ook zonder netwerk werkt, is de VNC-console in het klantenpaneel. Die hangt aan de virtualisatielaag of aan de aansluiting zelf, niet aan de netwerkstack van het gastsysteem. Log daar vooraf één keer in en verzeker u ervan dat u het root-wachtwoord kent.

Inventarisatie in vijf commando's

systemctl --version | head -n 1

systemctl is-active systemd-journald

journalctl --disk-usage

ls -d /var/log/journal /run/log/journal

df -h /var

Het vierde commando is het belangrijkste: het beantwoordt de vraag of uw journal een herstart overleeft, en het meldt voor de map die niet bestaat No such file or directory. Alle wijzigingen in dit artikel komen later in een eigen bestand onder /etc/systemd/journald.conf.d/ terecht. De meegeleverde /etc/systemd/journald.conf blijft onaangeroerd, en het terugdraaien bestaat uit twee commando's: bestand verwijderen, dienst opnieuw starten.

Het tijdvenster afbakenen in plaats van scrollen

Bijna elke storing heeft een tijdstempel. Daarmee begint de analyse, niet met de naam van de dienst.

journalctl --since "-30min"

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20"

journalctl --since yesterday --until today

--since en --until hebben de korte vormen -S en -U. Als tijdsaanduiding begrijpt journalctl absolute waarden in de vorm 2026-09-02 03:10:00, datums zonder tijd (dan geldt middernacht), de sleutelwoorden yesterday, today, tomorrow en now, plus relatieve waarden zoals -1h, -30min of 2 days ago.

Hier zit een valkuil die veel tijd kost: journalctl werkt in de lokale tijd van de server, terwijl applicaties vaak in UTC loggen. Wie een tijdstempel uit een applicatielog klakkeloos in --since zet, zoekt in de zomer twee uur naast de gebeurtenis. Controleer de tijdzone, of laat alles meteen in UTC weergeven:

timedatectl

journalctl --since "2026-09-02 01:10" --until "2026-09-02 01:20" --utc --no-pager

Controle: komt -- No entries -- terug, dan is ofwel het venster te smal ofwel de tijdzone verkeerd. Trek het venster bij wijze van test open naar een uur voordat u aan de filters gaat twijfelen.

Bootprocessen als tijdvenster

Vaak is het juiste stuk geen tijdbereik, maar één systeemstart. -b zonder waarde betekent de lopende, -b -1 die daarvoor.

journalctl --list-boots --no-pager

journalctl -b -1 -p err --no-pager

De lijst toont per bootproces één regel met een index, het lopende krijgt de 0. Verschijnt alleen deze ene regel, dan wordt het journal waarschijnlijk helemaal niet permanent opgeslagen. Dan antwoordt -b -1 op Debian 13 met No journal boot entry found for the specified boot (-1) en op Ubuntu 24.04 met No journal boot entry found from the specified boot offset (-1). Geen defect, maar de mededeling dat daar niets te halen valt.

Filteren op dienst, proces en prioriteit

De unit, en waarom de naam exact moet kloppen

journalctl -u nginx.service --since "-2h" --no-pager

-u vergelijkt op gelijkheid, niet op gelijkenis. Daaruit ontstaat een bijzonder vervelende fout, juist omdat er geen foutmelding bij komt: journalctl -u mysql levert op een Debian-systeem met MariaDB -- No entries -- op, hoewel het journal vol staat met databasemeldingen. mysql.service is daar alleen een alias voor mariadb.service. systemctl lost zulke aliassen op, het journal slaat op onder de echte naam. U krijgt dus een verkeerd antwoord dat er niet uitziet als een fout.

De echte naam haalt u uit het journal zelf. -F somt alle waarden op die een veld daar ooit heeft gehad:

journalctl -F _SYSTEMD_UNIT | sort | grep -i sql

-u accepteert bovendien patronen, waarmee de vraag van tafel is:

journalctl -u "mysql*" -u "mariadb*" -n 60 --no-pager

Dezelfde controle loont op Ubuntu 24.04 voor SSH, omdat de dienst daar via een socketactivering start en de logins niet per se onder de verwachte naam staan:

journalctl -F _SYSTEMD_UNIT | grep -i ssh

De identifier in plaats van de unit

Naast de unit is er de afzenderidentifier, dus dat wat klassiek syslog als programmanaam bijhoudt. Het filter daarvoor is -t:

journalctl -t sshd -t sshd-session -n 50 --no-pager

Waarom twee? OpenSSH plaatst de sessies sinds versie 9.8 in een eigen proces sshd-session. Op Debian 13 (OpenSSH 10.0) staat onder -t sshd daarom alleen nog dat de dienst luistert, terwijl elke login onder -t sshd-session valt. Debian 12 (9.2), Ubuntu 24.04 (9.6) en Ubuntu 22.04 (8.9) kennen die opsplitsing niet. Wie op Debian 13 alleen op -t sshd filtert, houdt een server voor rustig terwijl daar juist elke poging wordt gelogd. Robuuster is de weg via de unit, want de kindprocessen horen bij dezelfde:

journalctl -u ssh --since "-24h" --no-pager

Willekeurige velden, en hoe ze worden gecombineerd

Elk item draagt velden die u rechtstreeks als filter kunt schrijven, bijvoorbeeld _COMM (programmanaam), _PID, _UID, _SYSTEMD_UNIT of _TRANSPORT. Over de combinatieregels bestaan vaak verkeerde aannames:

• Twee filters op verschillende velden worden met EN gecombineerd.
• Twee filters op hetzelfde veld worden met OF gecombineerd.
• Eén enkel plusteken tussen twee groepen koppelt die groepen met OF.

journalctl _SYSTEMD_UNIT=ssh.service _UID=0 --since "-1h" --no-pager

journalctl _SYSTEMD_UNIT=ssh.service + _SYSTEMD_UNIT=nginx.service --since "-1h" --no-pager

Veldnamen staan in hoofdletters, er wordt vergeleken op de volledige waarde. Een journalctl unit=nginx is daarom geen filter op een deel van de tekst, maar een syntaxfout die journalctl met Failed to add match afdoet.

Prioriteiten

Elk item draagt een urgentieniveau van 0 tot 7. -p filtert daarop, altijd inclusief alle dringendere niveaus: -p err toont ook crit, alert en emerg.

journalctl -b -p err --no-pager

journalctl -u nginx.service -p 2..4 --since "-24h" --no-pager

En dan nu de valkuil waarop het filteren op prioriteit regelmatig stukloopt: wat een dienst naar de standaarduitvoer schrijft, komt standaard als info in het journal, ook als het op de standaardfoutuitvoer stond. Een programma dat een uitzondering met stacktrace uitgeeft, verschijnt daarmee als onschuldige bedrijfsmelding, en -p err verbergt die. Een passend niveau krijgen alleen programma's die rechtstreeks naar de journal-interface schrijven of hun regels van een syslog-prefix zoals <3> voorzien. Bij eigen diensten filtert u daarom op unit en tekst, bij systeemdiensten en bij de kernel is -p wel degelijk bruikbaar.

Zoeken in de tekst

journalctl -u nginx.service --since "-24h" --grep "upstream timed out" --no-pager

--grep (korte vorm -g) doorzoekt uitsluitend de meldingstekst, niet de overige velden. Het onderscheid tussen hoofdletters en kleine letters vervalt automatisch zolang het patroon volledig in kleine letters staat; zodra er één hoofdletter in voorkomt, wordt exact vergeleken. Beide zijn af te dwingen met --case-sensitive=yes of --case-sensitive=no. Reguliere expressies zijn toegestaan, de verticale streep werkt dus als OF.

De logs live meelezen

-f hangt zich aan het einde van het journal en toont nieuwe regels zodra ze binnenkomen. Zinvol is dat vrijwel alleen met een filter, anders raast het halve systeem voorbij. -n bepaalt hoeveel voorgaande regels eerst verschijnen; zonder opgave zijn dat er tien. Afsluiten doet u met Ctrl+C.

journalctl -u nginx.service -f -n 100

journalctl -f -u nginx.service -u php8.2-fpm.service

journalctl -f -p warning

De gebruikelijke gang van zaken bij een reproduceerbare fout: in de eerste sessie meelezen, in een tweede de fout uitlokken. Bij erg brede regels helpt -o cat, omdat dan alleen de meldingstekst zonder tijdstempel en afzender verschijnt.

Controle: komt er bij het uitlokken helemaal niets binnen, dan logt de dienst niet naar het journal maar naar een eigen bestand. Bij webservers en databases is dat het normale geval. Dan loopt de weg via de configuratie van de applicatie, niet via nog meer journalctl-opties.

Uitvoerformaten

Het standaardformaat is bedoeld voor mensen achter een terminal. Voor het vergelijken met andere logs, voor pipes en voor analyses zijn er geschiktere. Omschakelen doet u met -o:

journalctl -u ssh.service -n 1 -o verbose --no-pager

Dit ene commando is meer waard dan elke veldenlijst in een handleiding: u ziet welke velden uw items werkelijk dragen en kunt elk daarvan vervolgens als filter gebruiken. Vier opties vullen dat aan:

• --no-pager schakelt de pager uit. In scripts en voor elke pipe hoort deze optie erbij, anders wacht de aanroep op een toets die niemand indrukt.
• -r draait de volgorde om, de nieuwste regels staan bovenaan.
• -e springt in de pager meteen naar het einde.
• -x vult meldingen van systemd zelf aan met een verklarende catalogustekst.

Met --output-fields= laat de uitvoer zich indampen tot de interessante velden. Dat werkt alleen bij verbose, json en verwante formaten:

journalctl -u ssh.service --since "-1h" -o json --output-fields=MESSAGE,_PID --no-pager

Het journal over herstarts heen bewaren

Of het journal een herstart overleeft, beslist de standaardinstelling Storage=auto volgens een eenvoudige regel: bestaat /var/log/journal, dan wordt daarheen geschreven en blijft alles bewaard. Bestaat die map niet, dan komt alles in het werkgeheugen onder /run/log/journal terecht en is het na de volgende herstart verdwenen. Vertrouw niet op de distributie, tussen installatievarianten en cloudimages komen beide toestanden voor. Een journal in het werkgeheugen is de meest voorkomende verklaring waarom na een crash niemand meer kan zeggen wat eraan voorafging.

Zet u het om, stel dan in dezelfde werkstap meteen de limiet in. Achteraf gebeurt dat ervaringsgewijs niet meer:

mkdir -p /etc/systemd/journald.conf.d

cat > /etc/systemd/journald.conf.d/10-kh-journal.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=1month
EOF

systemctl restart systemd-journald

journalctl --flush

Storage=persistent maakt de map zelf aan, een mkdir is daarvoor niet nodig. journalctl --flush neemt over wat nog in /run staat naar /var/log/journal.

Controles, in deze volgorde:

systemd-analyze cat-config systemd/journald.conf | grep -v '^#'

ls -d /var/log/journal

journalctl -u systemd-journald -b -n 20 --no-pager

Het eerste commando toont de effectieve configuratie uit het hoofdbestand en alle aanvullende bestanden, dus dat wat de dienst werkelijk heeft ingelezen. Het derde is de typefouttest: staat daar een regel met Unknown key, dan werkt uw instelling niet. Afhankelijk van de systemd-versie luidt die Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring of Unknown key 'SystemMaxUsage' in section [Journal], ignoring.

Het sluitende bewijs is een echte herstart. Daarna moet journalctl --list-boots minstens twee regels tonen en moet journalctl -b -1 -n 20 items opleveren. Wie de map liever met de hand aanmaakt, volgt de onderstaande weg. De aanroep van systemd-tmpfiles zet daarbij eigenaar, rechten en de toegangslijsten die de juiste groepen het meelezen toestaan:

mkdir -p /var/log/journal

systemd-tmpfiles --create --prefix /var/log/journal

systemctl restart systemd-journald

Lezen zonder root

Een gewone gebruiker ziet alleen zijn eigen meldingen en krijgt daarbij de aanwijzing Hint: You are currently not seeing messages from other users and the system. met een verwijzing naar de groepen die alles mogen lezen. Op Debian en Ubuntu is dat meestal adm:

usermod -aG adm gebruikersnaam

Controle: het groepslidmaatschap geldt pas bij een nieuwe login. Dus uitloggen, opnieuw inloggen, dan id -nG en journalctl -n 5. Blijft de aanwijzing weg en verschijnen er systeemmeldingen, dan is het gelukt.

Beperk de grootte voordat de schijf het doet

De meegeleverde /etc/systemd/journald.conf somt alle sleutels op als uitgecommentarieerde regels met hun standaardwaarden en is daarmee de betrouwbaarste bron voor wat er op uw systeem op dit moment geldt. Na elke wijziging is systemctl restart systemd-journald nodig, daarna toont journalctl --disk-usage het resultaat.

Voor de directe maatregel op een volle schijf geldt een volgorde waarover velen struikelen: de opruimopties raken uitsluitend afgesloten journalbestanden aan, nooit het bestand dat op dat moment actief is. Zonder eerst te roteren gebeurt er ogenschijnlijk niets, en de uitvoer luidt zoiets als Vacuuming done, freed 0B of archived journals.

journalctl --rotate

journalctl --vacuum-time=7d

Meer daarover, samen met de overige ruimtevreters, staat in het artikel harde schijf vol onder Linux.

Een tweede reden voor ontbrekende regels is de ingebouwde rate limiting via RateLimitIntervalSec en RateLimitBurst: schrijft een dienst in korte tijd heel veel meldingen, dan gooit journald het overschot weg en noteert dat met een regel waarin het woord Suppressed staat. Heeft een log gaten terwijl de dienst aantoonbaar draaide, zoek dan eerst daarnaar:

journalctl -b --grep "Suppressed" --no-pager

Kernelmeldingen: journalctl -k en dmesg

-k toont uitsluitend kernelmeldingen en sluit daarbij -b in, beperkt de uitvoer dus automatisch tot het lopende bootproces. Wie na een herstart naar de oorzaak zoekt, moet het vorige uitdrukkelijk opvragen:

journalctl -k -p err --no-pager

journalctl -k -b -1 --no-pager

Het verschil met dmesg is de opslagplaats. dmesg leest de ringbuffer van de kernel: beperkt, loopt over, na een herstart leeg. Het journal bewaart dezelfde meldingen, mits het persistent is. Voor een incident van gisteren is journalctl -k dus de enige betrouwbare bron. Daarbij twee praktijktips: dmesg -T rekent de seconden sinds de start om naar kloktijden en zit er na lange looptijden licht naast, het journal houdt altijd de echte kloktijd aan. En kernel.dmesg_restrict staat op alle vier de distributies op 1, een aanroep zonder root mislukt daarom met Operation not permitted.

Waarom veel servers geen /var/log/syslog meer hebben

Het journal is geen aanvulling op de klassieke tekstbestanden, maar de vervanging ervan. /var/log/syslog en /var/log/auth.log ontstaan niet door systemd, maar door een extra syslog-dienst, meestal rsyslog. Dat is een apart pakket en het hoort bij minimale installaties van Debian 12 en Debian 13 niet meer bij de standaardlevering. Op de serverimages van Ubuntu 22.04 en 24.04 is het wel aanwezig.

ls -l /var/log/syslog /var/log/auth.log

systemctl status rsyslog --no-pager

Is er geen syslog-dienst geïnstalleerd, dan antwoordt het tweede commando met Unit rsyslog.service could not be found. Dat verklaart drie waarnemingen in één klap: handleidingen met tail -f /var/log/syslog mislukken met tail: cannot open '/var/log/syslog' for reading: No such file or directory, het zoeken naar inlogpogingen in /var/log/auth.log loopt dood, en fail2ban moet zijn gebeurtenissen uit het journal halen. Hoe u dat instelt, staat in het artikel fail2ban instellen.

rsyslog alsnog installeren, alleen omdat u die bestanden gewend bent, loont zelden: u slaat dan alles dubbel op en hebt bovendien een werkende logrotate-regel nodig. Zinvol is het wanneer logs naar een centraal systeem moeten.

Kant-en-klare zoekpatronen voor noodgevallen

Een dienst is gestorven of start voortdurend opnieuw

systemctl list-units --type=service --state=failed --no-pager

journalctl -b -p err --no-pager

journalctl -b --grep "Main process exited|Failed with result|Start request repeated" --no-pager

De derde regel vindt de meldingen waarmee systemd crashes en zijn ingebouwde startrem bevestigt. Wordt een crashdump interessant, dan maakt eerst dit bestand duidelijk wie daarvoor verantwoordelijk is:

cat /proc/sys/kernel/core_pattern

Staat daar een aanroep van systemd-coredump, dan somt coredumpctl list de aanwezige dumps op. Staat er iets anders of alleen core, dan is een andere handler verantwoordelijk en blijft coredumpctl leeg.

Geheugentekort

journalctl -k -b --grep "Out of memory|oom-kill" --no-pager

journalctl --since "-7d" --grep "Out of memory|oom-kill" --no-pager

journalctl -u systemd-oomd --since "-7d" --no-pager

Het tweede commando laat -k bewust weg en zoekt daardoor over bootprocessen heen. Het derde geldt voor Ubuntu 22.04 en 24.04, waar systemd-oomd standaard meedraait en hele control groups beëindigt voordat de kernel ingrijpt; op Debian hoort deze dienst niet bij de standaarduitrusting. Hoe u de meldingen uit elkaar houdt, staat in het artikel swap instellen en out-of-memory voorkomen.

Mislukte logins

journalctl -u ssh --since "-24h" --grep "Failed password|Invalid user" --no-pager

Interessanter dan de losse regels is de verdeling. De volgende regel telt de bronadressen en sorteert ze aflopend:

journalctl -u ssh --since "-24h" -g "Failed password" -o cat --no-pager | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

De truc is het tellen vanaf achteren: de melding eindigt altijd op from ADRES port NUMMER ssh2, het op drie na laatste veld is dus het adres, ongeacht of er een geldige of een verzonnen gebruikersnaam voor stond en ongeacht of het IPv4 of IPv6 is. -o cat is daarbij verplicht, omdat anders het tijdstempel en de afzender de veldtelling verschuiven. De tegenproef voor geslaagde logins:

journalctl -u ssh --since "-7d" -g "Accepted (publickey|password)" -o cat --no-pager

Wat gebeurde er om 03:14, en wat kwam daarvoor?

journalctl --since "2026-09-02 03:10" --until "2026-09-02 03:20" -o short-iso --no-pager

journalctl -b -1 -n 100 --no-pager

journalctl _PID=1234 --since "-1h" --no-pager

Het tweede commando toont de laatste honderd regels voor het vorige einde. Een geordende afsluiting herkent u eraan dat systemd daar rij na rij diensten beëindigt. Breekt de uitvoer midden in de normale werking af, dan was het een crash, een harde reset of een stroomuitval. Bij het derde commando geldt: procesnummers worden hergebruikt, zonder tijdvenster mengt u mogelijk twee verschillende programma's in één uitvoer.

Veelvoorkomende fouten en oplossingen

No journal files were found.: er zijn geen leesbare journalbestanden. Ofwel draait systemd-journald niet, ofwel hebt u als gewone gebruiker geen toegang. Controleer eerst systemctl is-active systemd-journald, herhaal het daarna als root.

-- No entries --: het filter heeft niets gevonden. Dat is geen foutmelding, maar een correct antwoord op een mogelijk verkeerde vraag. De drie meest voorkomende oorzaken: een unitnaam die alleen een alias is, een te smal tijdvenster, en een -k terwijl de gezochte melding helemaal niet van de kernel kwam.

Hint: You are currently not seeing messages from other users and the system.: u leest als gewone gebruiker. Laat uzelf opnemen in de groep adm en log opnieuw in, of werk meteen met sudo.

No journal boot entry found for the specified boot (-1) respectievelijk No journal boot entry found from the specified boot offset (-1): in het journal staat geen eerder bootproces. Normaal zolang het journal alleen in het werkgeheugen staat.

Failed to add match: de expressie is geen geldig veldfilter. Veldnamen staan in hoofdletters, er wordt vergeleken op de volledige waarde. Voor gedeeltelijke treffers in de meldingstekst is --grep de juiste optie.

Unknown key name 'SystemMaxUsage' in section 'Journal', ignoring: een typefout in het aanvullende bestand. systemd leest de regel over en werkt met de standaardwaarde verder. Te vinden via journalctl -u systemd-journald -b.

Vacuuming done, freed 0B of archived journals: er viel niets gearchiveerds te verwijderen, omdat het actieve bestand de ruimte in beslag neemt. Eerst journalctl --rotate, daarna opnieuw opruimen.

Operation not permitted bij dmesg: kernel.dmesg_restrict staat op 1. Herhaal het als root of wijk uit naar journalctl -k.

File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.: de server is hard uitgevallen terwijl een journalbestand open stond. journald hangt een tilde aan de oude naam en begint een nieuw bestand. De toestand van alle bestanden controleert journalctl --verify, dat per bestand een regel met PASS uitgeeft; klachten betreffen in de regel precies die oude bestanden met de tilde.

Verschillen tussen Debian 13, Debian 12, Ubuntu 24.04 en 22.04

• Debian 13 (trixie): systemd 257. OpenSSH 10.0, logins staan onder de identifier sshd-session. rsyslog ontbreekt bij minimale installaties, /var/log/syslog is er dan niet. systemd-oomd hoort niet bij de standaarduitrusting.
• Debian 12 (bookworm): systemd 252. OpenSSH 9.2, alles onder sshd. rsyslog afhankelijk van de installatievariant aanwezig, /var/log/syslog dus niet gegarandeerd. systemd-oomd hoort niet bij de standaarduitrusting.
• Ubuntu 24.04 LTS: systemd 255. OpenSSH 9.6, alles onder sshd. rsyslog aanwezig. systemd-oomd standaard actief. SSH loopt via een socketactivering, zoek daarom de werkelijke unitnaam in het journal op.
• Ubuntu 22.04 LTS: systemd 249. OpenSSH 8.9, alles onder sshd. rsyslog aanwezig. systemd-oomd standaard actief. Oudste van de vier systemd-versies, enkele nieuwere uitvoerformaten ontbreken daar.

Gelijk is op alle vier de systemen het wezenlijke: dezelfde filters, dezelfde prioriteiten, hetzelfde configuratiebestand en dezelfde regel dat /var/log/journal over de houdbaarheid beslist.

De volgorde die zich in de dagelijkse praktijk bewijst: eerst het tijdvenster, dan de unit, dan de prioriteit, en tot slot een zoekpatroon. Wie zo te werk gaat, heeft voor de meeste storingen geen drie commando's nodig. En wie er één keer voor zorgt dat het journal herstarts doorstaat en toch een bovengrens houdt, kan de vraag naar het waarom ook dan nog beantwoorden wanneer de server allang weer draait.