Journalctl Comandi Linux: 15 Istruzioni Essenziali

Venerdì sera. 23:45. Un servizio critico va in crash su un server che regge il carico di 2.000 utenti. Ti colleghi in SSH e la prima domanda è: dove cerco? Se cerchi ancora sfogliando i file di testo in /var/log, stai perdendo tempo e informazioni preziose. Systemd ha cambiato il modo in cui Linux registra gli eventi, raccogliendo metadati strutturati che i file di testo piatto non possono contenere. Padroneggiare i journalctl comandi linux significa passare dal cercare un ago in un pagliaio all’estrazione chirurgica dell’evento esatto in pochi secondi. Quando gestisci l’infrastruttura per un ente sanitario pubblico con centinaia di VM, la velocità di diagnosi è direttamente proporzionale alla qualità del servizio che eroghi. Ecco 15 comandi per leggere, filtrare e gestire i log di sistema senza perdere la ragione.

Prerequisiti per i journalctl comandi linux

Prima di iniziare, devi verificare due cose. La tua distribuzione deve usare systemd come init system, requisito standard su Ubuntu 16.04+, RHEL 7+, Debian 8+ e quasi tutte le distribuzioni moderne. Per leggere i log di sistema di tutti gli utenti, hai bisogno dei privilegi di root o di appartenere al gruppo systemd-journal. Senza questo gruppo, un utente normale vedrà solo i log dei propri processi, il che rende il troubleshooting praticamente impossibile.

journalctl vs /var/log — perché systemd ha cambiato tutto

Nei vecchi sistemi SysVinit, i demoni scrivevano i log in file di testo in /var/log. Un approccio semplice, ma con limiti pesanti. Non c’era un formato standard, non c’era rotazione affidabile e i metadati erano inesistenti. Se volevi sapere quale utente o PID aveva generato un errore, dovevi sperare che il demone lo avesse incluso nel messaggio.

Systemd risolve questo problema alla radice. Journald, il demone di logging di systemd, raccoglie i log in un formato binario indicizzato. Registra automaticamente metadati come UID, GID, PID, cgroup e timestamp con precisione al microsecondo. Non stai più leggendo righe di testo. Stai interrogando un database strutturato. Questo ti permette di incrociare i dati in modi impossibili con il semplice grep.

Leggere i log in tempo reale (-f, -n)

Il comando base apre l’intero journal. Attenzione, su server attivi da mesi l’output può essere enorme.

journalctl

Per leggere i log mentre vengono generati, usi l’opzione follow. È l’equivalente di tail -f, ma con la potenza di journald.

journalctl -f

Se vuoi vedere solo le ultime 50 righe per un controllo rapido prima di iniziare a seguire il flusso:

journalctl -n 50 -f

Filtrare per servizio, unità, priorità

Il vero vantaggio di journalctl è la capacità di filtrare i log con precisione. Se devi diagnosticare un problema sul web server, non ti interessano i messaggi del cron o del kernel.

Per isolare i log di un servizio specifico, usi l’opzione unit:

journalctl -u nginx

Per vedere solo i messaggi di errore, usi il filtro per priorità. I livelli vanno da 0 (emerg) a 7 (debug). L’errore corrisponde al livello 3.

journalctl -p err

Se vuoi includere anche i warning senza scendere fino ai messaggi informativi, specifichi un range:

journalctl -p warning..err

Questo comando ti restituisce tutti i messaggi con priorità warning (4), notice (3), e err (3). Pratico per ottenere un quadro completo dei problemi senza il rumore di fondo.

Filtrare per data e intervallo di tempo

Quando indaghi su un incidente, il tempo è il tuo filtro più potente. Perché scorrere migliaia di righe vecchie quando sai che il problema è iniziato il 1 aprile?

journalctl -u sshd --since "2026-04-01" --until "2026-04-20"

Puoi usare formati relativi. Per controllare cosa è successo nelle ultime due ore:

journalctl --since "2 hours ago"

Oppure per verificare gli eventi di ieri:

journalctl --since yesterday

Log del boot corrente e dei boot precedenti

I log di avvio sono spesso i più critici per diagnosticare problemi hardware o di servizi che non partono. Journald tiene traccia di ogni boot separatamente.

Per vedere i log del boot corrente:

journalctl -b

Se il server è crashato e si è riavviato, devi guardare i log del boot precedente. L’opzione -1 si riferisce proprio al boot prima dell’attuale.

journalctl -b -1

Per vedere la lista di tutti i boot registrati con i relativi offset numerici:

journalctl --list-boots

Questo comando ti mostra un elenco con timestamp e kernel version. Ti basta usare il numero corretto con l’opzione -b per saltare al boot esatto che ti interessa.

Trovare i servizi che hanno crashato

Cercare la stringa ‘failed’ nei log è un’operazione comune durante il post-mortem di un incidente. Journalctl offre un filtro interno simile a grep.

journalctl -g 'failed'

L’opzione -g evidenzia le corrispondenze e ti permette di scorrere i risultati. Puoi combinare questo filtro con altri parametri per restringere il campo. Ad esempio, cerca i failed solo nel servizio nginx durante l’ultimo boot:

journalctl -u nginx -b -g 'failed'

Esportare i log in formato leggibile

A volte devi condividere i log con un vendor o analizzarli con script esterni. Il formato binario di default non è l’ideale. Puoi esportare i log in formato JSON per l’elaborazione automatizzata.

journalctl -u nginx -o json-pretty

Se preferisci un formato cat compatto senza metadati extra per una rapida lettura:

journalctl -u nginx -o cat

L’opzione cat mostra solo il messaggio, senza timestamp o nome dell’unità. Utile per leggere lunghe sequenze di output di un demone.

Configurare la retention dei log (journald.conf)

Di default, journald memorizza i log in /run/log/journal, che viene svuotato al riavvio. Per mantenere i log persistenti, assicurati che la directory /var/log/journal esista. I log possono crescere rapidamente e consumare tutto lo spazio su disco se non li gestisci.

Per controllare lo spazio occupato:

journalctl --disk-usage

Per eliminare i log più vecchi di 30 giorni:

journalctl --vacuum-time=30d

Per forzare la rimozione dei log finché l’archivio non scende sotto 1GB:

journalctl --vacuum-size=1G

Per un controllo permanente, modifica il file /etc/systemd/journald.conf. Imposta SystemMaxUse=500M per limitare l’uso del disco e MaxRetentionSec=30day per la retention. Ricorda di riavviare il servizio con systemctl restart systemd-journald dopo le modifiche.

[Leggi anche: Hardening SSH su Linux: 10 Impostazioni Essenziali]

I 15 comandi journalctl da memorizzare — cheat sheet finale

Ecco i 15 comandi da tenere a portata di mano sul tuo terminale:

1. journalctl – Legge l’intero journal
2. journalctl -f – Mostra i log in tempo reale
3. journalctl -n 50 – Ultime 50 righe
4. journalctl -u nginx – Filtra per unità o servizio
5. journalctl -u sshd --since "2026-04-01" --until "2026-04-20" – Filtra per data
6. journalctl -p err – Solo messaggi di errore
7. journalctl -p warning..err – Range di priorità
8. journalctl -g 'failed' – Cerca una stringa
9. journalctl -b – Log del boot corrente
10. journalctl -b -1 – Log del boot precedente
11. journalctl --list-boots – Lista dei boot registrati
12. journalctl --disk-usage – Spazio su disco occupato
13. journalctl --vacuum-time=30d – Elimina log più vecchi di 30 giorni
14. journalctl --vacuum-size=1G – Riduce i log a 1GB
15. journalctl -u nginx -o json-pretty – Esporta in formato JSON

Errori comuni e troubleshooting

L’errore più frequente è “No journal files were found”. Accade quando journald non ha i permessi di scrittura o la directory di persistenza non esiste. Crea la directory con mkdir -p /var/log/journal e riavvia il servizio.

Un altro problema comune è la mancanza di log per un utente non root. Se un utente normale non vede i log di sistema, aggiungilo al gruppo systemd-journal con usermod -aG systemd-journal nomeutente.

Se i log sembrano troncati o incompleti, controlla le limitazioni in journald.conf. La direttiva RateLimitIntervalSec può scartare messaggi troppo frequenti durante un attacco o un loop di errori. Aumenta i limiti o imposta RateLimitIntervalSec=0 per disabilitare il rate limiting in ambienti di test.

Conclusioni con takeaway operativi

Saper usare journalctl non è un optional per un sysadmin moderno. È la differenza tra risolvere un incidente in 3 minuti o in 3 ore. I file in /var/log esistono ancora per retrocompatibilità, ma l’infrastruttura di logging di Linux è systemd. Abituati a filtrare per servizio, priorità e finestra temporale. Imposta la retention su journald.conf per evitare sorprese sul disco. Tieni a portata di mano il cheat sheet con i 15 comandi. La prossima volta che un servizio va in crash alle 3 di notte, saprai esattamente dove guardare.

Per approfondire tutte le opzioni disponibili, consulta la documentazione ufficiale su freedesktop.org.