Su una distribuzione basata su systemd (la stragrande maggioranza oggi: Ubuntu, Debian, Fedora, Arch...) i log di sistema e dei servizi non vivono più solo in file di testo sparsi in /var/log/, ma in un journal binario centralizzato, interrogabile con un unico comando: journalctl. Conoscerne bene i filtri fa risparmiare minuti preziosi ogni volta che un servizio non parte o si comporta in modo strano.
I log di un singolo servizio
journalctl -u nginx.service
Mostra solo le righe di log generate da quel systemd unit specifico — molto più mirato di grep su un log generico condiviso da tutto il sistema.
Seguire i log in tempo reale (l'equivalente di tail -f)
journalctl -u nginx.service -f
Utile mentre riavvii un servizio o riproduci un problema, per vedere le righe apparire man mano che vengono scritte.
Filtrare per intervallo di tempo
journalctl --since "2026-07-17 09:00" --until "2026-07-17 10:30"
journalctl --since "1 hour ago"
journalctl --since yesterday
Il parser degli orari accetta espressioni naturali (yesterday, "2 hours ago", today), oltre a date/orari precisi — comodo per non dover calcolare a mano il timestamp esatto quando ricordi solo approssimativamente quando è iniziato un problema.
Filtrare per priorità (solo errori, o solo warning e sopra)
journalctl -p err # solo errori e più gravi
journalctl -p warning..err # da warning a err (intervallo)
Le priorità seguono la scala syslog classica: emerg, alert, crit, err, warning, notice, info, debug. Filtrare per priorità è spesso il modo più rapido di trovare un problema in un sistema che genera molti log informativi "di rumore" attorno al vero errore.
Log dell'intero boot corrente (o di un boot precedente)
journalctl -b # boot corrente
journalctl -b -1 # boot precedente (utile dopo un crash/riavvio inatteso)
journalctl --list-boots # elenca tutti i boot disponibili nel journal
journalctl -b -1 è spesso la prima cosa da controllare dopo un riavvio imprevisto del server: mostra cosa è successo esattamente prima dello spegnimento, incluso l'eventuale ultimo messaggio del kernel prima di un kernel panic.
Output in formato JSON per script e automazioni
journalctl -u myapp.service -o json-pretty --since "10 min ago"
Utile quando vuoi processare i log con jq o inviarli a un sistema di monitoraggio esterno, invece di fare parsing fragile di testo formattato per l'occhio umano.
Il journal persistente: verificare che non vada perso al riavvio
Di default su alcune distribuzioni il journal è solo in RAM (volatile) e viene perso a ogni riavvio. Per renderlo persistente su disco:
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
Vale la pena anche limitare lo spazio massimo occupato, per evitare che il journal cresca indefinitamente su un server con poco spazio disco:
# in /etc/systemd/journald.conf
SystemMaxUse=500M