journalctl cheat sheet: seguire e filtrare i log Linux

journalctl in una riga: journalctl -u <service> -f segue il log di un servizio in diretta, journalctl -u <service> -n 100 mostra le ultime 100 righe, e journalctl --since "1 hour ago" mostra tutto ciò che è recente. Copre il 90% dei momenti «perché questo servizio non risponde». Il resto del cheat sheet sono i pattern da copiare e incollare che ti risparmiano la rilettura del man page alle 2 di notte — filtraggio per unità, tempo, priorità e boot, più i comandi di pulizia che impediscono al journal di divorarti il disco. Ogni comando qui sotto funziona così com’è su qualsiasi distro systemd (Ubuntu, Debian, Fedora, Arch).

Cos’è journalctl e perché non leggere direttamente /var/log/syslog?

Il logging alla vecchia maniera scriveva file di testo sotto /var/log — syslog, auth.log, messages. systemd ha sostituito tutto con il journal: un log binario e indicizzato gestito da systemd-journald. Un semplice grep non può leggerlo; journalctl è l’unica porta d’ingresso, e in cambio ottieni filtri per servizio, tempo, boot e severità senza acrobazie di regex.

Il modello mentale è semplice: il journal conserva tutto, e journalctl è lo strumento di interrogazione. Un servizio non ha bisogno del proprio file di log — tutto ciò che scrive su stdout/stderr mentre gira sotto systemd finisce nel journal automaticamente. Per questo journalctl -u nginx funziona anche quando non hai idea di dove nginx configuri il suo error log.

Una avvertenza: su alcune installazioni minime il journal è volatile (salvato in /run, cancellato al reboot) perché /var/log/journal non esiste. Si sistema una volta per tutte:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

Come vedere le ultime 100 righe di un log?

-n limita l’output alle N righe più recenti (il default è 10):

journalctl -n 100                      # le ultime 100 righe di tutto
journalctl -u nginx -n 100             # le ultime 100 righe di un'unità
journalctl -n 100 --no-pager           # stampa ed esce — perfetto per una pipe

--no-pager conta più di quanto sembri: senza, journalctl apre less e il tuo script, la tua pipe o il tuo one-liner ssh restano appesi in attesa di un tasto. Ogni comando il cui output finisce in una pipe dovrebbe portarlo.

Come seguire i log in diretta, come tail -f?

Il flag -f è il tail -f di journalctl — fa scorrere le nuove entry appena nascono:

journalctl -f                    # tutto, in diretta
journalctl -u sshd -f            # solo il demone SSH, in diretta
journalctl -u ollama -f -n 50    # in diretta, ma partendo dalle ultime 50 righe

È il comando da tenere aperto in un secondo terminale mentre riavvii un servizio nel primo: systemctl restart nginx in un pannello, journalctl -u nginx -f nell’altro, e la causa del crash di norma si annuncia da sola nel giro di pochi secondi. Io eseguo esattamente questo ciclo sul mio homelab ogni volta che un container o un servizio fa i capricci.

Come mostrare i log di un servizio specifico?

-u filtra per unità systemd:

journalctl -u nginx                    # un'unità, tutta la cronologia
journalctl -u nginx -u redis           # più unità in una volta
journalctl _SYSTEMD_UNIT=nginx.service # l'alternativa con corrispondenza esatta

Un’unità può generare unità ausiliarie che si tengono l’output interessante — un’app web che crasha a volte logga il vero errore sotto un’altra unità. Se -u <service> non restituisce nulla ma il servizio gira evidentemente, trova prima il nome vero dell’unità:

systemctl list-units --type=service | grep -i <guess>

Lo stesso pattern -u vale per i timer (systemctl list-timers mostra i nomi) e per i servizi utente — per tutto ciò che gira sotto systemd --user aggiungi --user:

journalctl --user -u pipewire -n 50

Come filtrare i log per data?

--since e --until accettano timestamp, ma anche formule relative molto permissive:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Abbina una finestra temporale a un’unità e hai il triage di un incidente in una riga: «cosa ha loggato l’API tra le 9:00 e il momento in cui è crollata?». Su una singola macchina è più veloce di qualsiasi log aggregator.

Come mostrare solo gli errori (o i warning)?

-p filtra per priorità, usando i nomi di severità syslog:

journalctl -p err -b              # solo errori, da questo boot
journalctl -p warning..alert -u nginx   # un intervallo di severità

Le priorità in ordine decrescente: emerg, alert, crit, err, warning, notice, info, debug. Quando una macchina «fa le bizze», journalctl -p err -b --since today è il controllo di sanità più rapido — risponde alla domanda «sta davvero fallendo qualcosa?» senza il rumore delle righe info di routine.

Come vedere i log del boot precedente?

I servizi che crashano all’avvio producono righe di log prima del boot corrente, e journalctl mostra in silenzio solo quello attuale. -b seleziona i boot:

journalctl -b                 # solo il boot corrente
journalctl -b -1              # il boot precedente
journalctl -b -1 -u sshd      # perché SSH è morto l'ultima volta
journalctl --list-boots       # l'indice dei boot salvati

È il flag più utile di tutti per lo scenario «si è rotto, ho riavviato, e ora l’errore non lo vedo più» — l’errore c’è ancora, un boot indietro.

Riferimento rapido: i flag da ricordare a memoria

Obiettivo	Comando
Seguire un servizio in diretta	journalctl -u <svc> -f
Le ultime 100 righe	journalctl -n 100
Dall’ultima ora	journalctl --since "1 hour ago"
Errori di questo boot	journalctl -p err -b
Boot precedente	journalctl -b -1
Spazio disco del journal	journalctl --disk-usage
Output leggibile dalla macchina	journalctl -o json-pretty
Solo messaggi del kernel	journalctl -k

Come impedire al journal di riempire il disco?

Prima guarda quanto costa, poi metti un tetto:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # conserva i 500 MB più recenti
sudo journalctl --vacuum-time=30d      # conserva gli ultimi 30 giorni

Per rendere il tetto permanente, metti SystemMaxUse=500M nella sezione [Journal] di /etc/systemd/journald.conf, poi sudo systemctl restart systemd-journald. Tra il tetto di dimensione e il filtro per boot qui sopra, il journal resta uno strumento invece di diventare una lenta perdita di disco.

journalctl vs dmesg vs /var/log — dove guardare per primo?

• journalctl — il comportamento di applicazioni e servizi. Tutto ciò che systemd gestisce sta qui, indicizzato e filtrabile. La prima fermata di default.
• journalctl -k / dmesg — kernel e hardware: kill OOM, reset USB, errori disco. Se un processo è morto senza spiegazione, cerca qui l’OOM killer prima di incolpare l’app.
• /var/log/<app>/ — solo per le app che fanno logging su file per conto loro (access log di nginx, PostgreSQL). E anche lì, gli errori di avvio di norma finiscono comunque nel journal.

Lo stesso workflow si estende ai servizi AI in locale — quando un’unità ollama serve si blocca, journalctl -u ollama -n 100 mostra subito il fallimento del caricamento del modello, come dettagliato nel confronto tra Ollama e LM Studio.

Ecco tutto il cheat sheet: -u per l’unità, -f per seguire, -n per le righe, --since per il tempo, -p per la severità, -b per i boot. Sei flag coprono quasi ogni domanda di log che una macchina Linux ti farà.