Gestione dei log in Linux: uso dei comandi journalctl per i log di systemd

Livello: Principiante
Tempo stimato: ~20 minuti
Obiettivo: Imparare a interrogare, filtrare e gestire i log di sistema e dei servizi, utilizzando i log di Linux per la risoluzione dei problemi e per mantenere la disponibilità del server.

Introduzione

Una gestione dei log in Linux affidabile è essenziale per mantenere la disponibilità del server ed eseguire la diagnostica dei server Linux. Quando si amministrano server web, è necessario analizzare i log di sistema con journalctl per individuare rapidamente la causa di un problema. Systemd (il sistema di init e gestore dei servizi della maggior parte delle moderne distribuzioni Linux) raccoglie i log di sistema (registri generali delle operazioni di sistema e degli eventi a livello di sistema). Un singolo log (la registrazione degli eventi che si verificano all'interno di un sistema operativo o di un'applicazione) viene raccolto da Systemd-journald (un servizio di sistema che raccoglie e archivia i dati di log) e memorizzato nel Journal (i dati di log in formato binario generati e gestiti da systemd-journald). Per visualizzare questi dati si usa Journalctl (un'utilità da riga di comando per interrogare e visualizzare i log di systemd). Questo tutorial si concentra sull'uso dei comandi journalctl per interrogare, filtrare e gestire i log di systemd con journalctl. Al termine, saprete muovervi con sicurezza nella riga di comando e utilizzare i log di Linux per la risoluzione dei problemi in modo efficiente.

Prerequisiti

Prima di iniziare, assicuratevi che siano soddisfatte le seguenti condizioni:

• Sistema operativo: Ubuntu 20.04/22.04/24.04 LTS, Debian 11/12/13 oppure AlmaLinux/Rocky 8/9/10
• Requisiti hardware e di rete: nessuno (questa guida utilizza utilità di base da riga di comando)
• Accesso: accesso sudo o root al server
• Conoscenze richieste: utilizzo di base della riga di comando di Linux

Passaggio 1: Gestione dei log in Linux: log volatili e persistenti

Per impostazione predefinita, alcuni sistemi configurano il journal per utilizzare log volatili (log memorizzati solo nella RAM e persi al riavvio). Per una gestione dei log in Linux efficace servono log persistenti (log salvati su disco che sopravvivono ai riavvii), in modo da poter analizzare i crash anche dopo un riavvio.

Eseguite il comando seguente per verificare la configurazione dell'archiviazione:

sudo grep -i 'storage' /etc/systemd/journald.conf

Output previsto:

#Storage=auto

Dovreste vedere un output che indica se l'archiviazione è impostata su auto, persistent o volatile. La riga commentata #Storage=auto indica che viene utilizzato il comportamento predefinito auto.

Su Ubuntu 24.04 e Debian 13 la directory /var/log/journal esiste già e la registrazione persistente funziona senza ulteriori configurazioni. Se la directory manca (ad esempio su una nuova installazione di AlmaLinux) e volete forzare la registrazione persistente, create la directory e riavviate il sistema di logging di systemd (il servizio systemd-journald gestisce questa directory):

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

Sui sistemi AlmaLinux/RHEL è inoltre necessario trasferire (flush) i log dalla posizione volatile /run/log/journal al nuovo archivio persistente su disco:

sudo journalctl --flush

Non dovreste vedere alcun output. Ciò conferma che il servizio è stato riavviato correttamente e che ora scriverà dati persistenti su disco.

Passaggio 2: Comandi journalctl di base per i log di systemd

Per visualizzare tutte le voci disponibili, utilizzate il comando predefinito.

Eseguite il comando seguente:

sudo journalctl

Output previsto:

May 20 10:00:00 server systemd[1]: Started Logging Service.
May 20 10:00:01 server kernel: Linux version 5.15.0-101-generic...

Dovreste vedere un elenco paginato di tutti i log di systemd del vostro server. Premete q per uscire dal pager.

Per analizzare i log con journalctl in modo efficace, raramente serve leggere tutto dall'inizio. È possibile invertire l'output per visualizzare per prime le voci più recenti con l'opzione -r.

Eseguite il comando seguente:

sudo journalctl -r

Output previsto:

May 23 20:00:00 server sshd[1234]: Accepted publickey for user from 192.168.1.50...
May 23 19:59:58 server systemd[1]: Session 4 created for user.

Dovreste vedere le voci di log più recenti nella parte alta dello schermo. È una tecnica fondamentale per analizzare rapidamente i log con journalctl dopo un incidente.

Passaggio 3: Come controllare i log di un servizio

Spesso è necessario analizzare una specifica unit (un oggetto che systemd è in grado di gestire), ad esempio una service unit (un tipo di unit che controlla un servizio, come nginx o sshd). Utilizzate l'opzione -u per controllare i log di un servizio specifico, come il web server nginx.

Eseguite il comando seguente (supponendo che il servizio sia installato, ad esempio tramite sudo apt install nginx -y oppure sudo dnf install nginx -y):

sudo journalctl -u nginx

Output previsto:

May 23 18:00:00 server systemd[1]: Starting A high performance web server and a reverse proxy server...
May 23 18:00:01 server systemd[1]: Started A high performance web server and a reverse proxy server.

Dovreste vedere solo le voci di log generate dal servizio nginx. Questo aiuta a isolare gli errori del traffico web dagli altri eventi di sistema in background. Se il servizio non è installato, vedrete semplicemente -- No entries --.

Per controllare i log del demone SSH, il nome della unit varia in base alla distribuzione.

Per Ubuntu/Debian, eseguite:

sudo journalctl -u ssh

Per AlmaLinux/RHEL/Rocky, eseguite:

sudo journalctl -u sshd

Output previsto:

May 23 19:50:00 server sshd[1234]: Invalid user admin from 10.0.0.5 port 55432
May 23 19:55:00 server sshd[1235]: Accepted publickey for root from 10.0.0.2 port 44322

Dovreste vedere i tentativi di autenticazione e gli eventi del demone SSH.

Passaggio 4: Filtrare i log con journalctl per intervallo di tempo e tipo

Quando si gestiscono grandi quantità di dati, è necessario il filtraggio dei log (il processo di restringere l'output dei log in base a criteri specifici). Il filtraggio dei log con journalctl per intervallo di tempo è estremamente utile quando un'interruzione si è verificata in un momento noto.

Per visualizzare i messaggi generati dall'ultimo avvio, consultiamo i log di avvio (registrazioni degli eventi che si verificano durante il processo di avvio del sistema).

Eseguite il comando seguente:

sudo journalctl -b

Output previsto:

May 23 08:00:00 server kernel: Linux version 5.15.0-101-generic...
May 23 08:00:00 server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz...

Dovreste vedere un output che parte dal primissimo evento della sequenza di avvio corrente.

Per il filtraggio dei log con journalctl basato sul tempo, utilizzate --since e --until.

Eseguite il comando seguente:

sudo journalctl --since "1 hour ago"

Output previsto:

May 23 19:00:00 server cron[567]: (root) CMD (/usr/local/bin/backup.sh)
May 23 19:05:00 server sudo[580]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls

Dovreste vedere tutti gli eventi verificatisi negli ultimi 60 minuti.

Per visualizzare i log del kernel (messaggi generati dal kernel Linux, tipicamente eventi relativi a hardware e driver), utilizzate l'opzione -k.

Eseguite il comando seguente:

sudo journalctl -k

Output previsto:

May 23 08:00:00 server kernel: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex
May 23 08:00:01 server kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Dovreste vedere messaggi del kernel di basso livello, utili per diagnosticare problemi hardware o dei driver.

Passaggio 5: Filtrare per priorità

Ogni voce ha una priorità (il livello di gravità assegnato a un messaggio di log). I livelli vanno da Debug (il livello di priorità più basso, usato per informazioni dettagliate di troubleshooting) a Error (un livello di priorità che indica un guasto in un servizio o in un processo). Un livello controllato di frequente è Warning (un livello di priorità che indica potenziali problemi che al momento non sono errori).

Per il filtraggio dei log con journalctl per priorità, utilizzate l'opzione -p.

Eseguite il comando seguente per visualizzare solo gli errori:

sudo journalctl -p err

Output previsto:

May 23 10:15:20 server systemd[1]: Failed to start Custom Application Service.
May 23 14:30:00 server sshd[1122]: error: kex_exchange_identification: Connection closed by remote host

Dovreste vedere un elenco sintetico contenente solo i messaggi di livello error, con le normali operazioni escluse.

Eseguite il comando seguente per visualizzare avvisi ed errori:

sudo journalctl -p warning

Output previsto:

May 23 10:15:15 server systemd-udevd[330]: vda: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/vda' failed with exit code 1.
May 23 10:15:20 server dhcpcd[400]: eth0: no IPv6 Routers available

Dovreste vedere sia gli avvisi sia gli errori, ottenendo una visione più ampia dei potenziali problemi. Su un sistema operativo appena installato è normale vedere messaggi di avviso di routine da servizi come multipathd, irqbalance, dhcpcd o udev, anziché guasti critici dei servizi. L'output esatto dipende in larga misura dalla configurazione e dall'ambiente del vostro sistema.

Passaggio 6: Come monitorare i log di Linux in tempo reale

Quando si applicano modifiche alla configurazione o si riproduce un problema, è preferibile monitorare i log di Linux in tempo reale. Utilizzate l'opzione -f (follow).

Eseguite il comando seguente:

sudo journalctl -f

Output previsto:

May 23 20:05:00 server sudo[2001]: user : TTY=pts/1 ; PWD=/ ; USER=root ; COMMAND=/bin/bash
May 23 20:05:00 server su[2002]: (to root) user on pts/1
May 23 20:05:00 server su[2002]: pam_unix(su:session): session opened for user root by user(uid=1000)

Dovreste vedere le ultime voci di log e il terminale resterà in attesa, mostrando i nuovi eventi man mano che si verificano. Premete Ctrl+C per uscire.

Per monitorare in tempo reale i log del demone SSH, il nome della unit varia in base alla distribuzione.

Per Ubuntu/Debian, eseguite:

sudo journalctl -u ssh -f

Per AlmaLinux/RHEL/Rocky, eseguite:

sudo journalctl -u sshd -f

Output previsto:

May 23 20:10:15 server sshd[2100]: Connection from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: Accepted publickey for admin from 192.168.1.100 port 45678
May 23 20:10:17 server sshd[2100]: pam_unix(sshd:session): session opened for user admin by (uid=0)

Dovreste vedere in diretta i tentativi di autenticazione SSH nel momento in cui avvengono.

Passaggio 7: Spazio su disco e rotazione dei log

Il journal di systemd può crescere notevolmente nel tempo. La pratica di archiviare ed eliminare i vecchi log per risparmiare spazio si chiama rotazione dei log. È possibile verificare quanto spazio occupa attualmente il journal di systemd.

Eseguite il comando seguente:

sudo journalctl --disk-usage

Output previsto:

Archived and active journals take up 200.0M in the file system.

Dovreste vedere un output che indica lo spazio totale occupato dai file di log.

Per eseguire manualmente la rotazione dei log e liberare spazio su disco, è possibile ripulire i dati (vacuum) per tempo o per dimensione.

Eseguite il comando seguente per mantenere solo gli ultimi 500 MB di dati:

sudo journalctl --vacuum-size=500M

Output previsto:

Vacuuming done, freed 0B of archived journals from /var/log/journal.

Dovreste vedere un output che indica che i file meno recenti sono stati eliminati finché la dimensione totale non è scesa sotto i 500 MB.

Verifica

Per assicurarvi che la configurazione del logging funzioni correttamente e che l'archiviazione persistente sia attiva:

1. Verificate che la posizione di archiviazione dei log sia stata creata:

   ls -ld /var/log/journal

   Dovreste vedere una directory di proprietà di root. A seconda della distribuzione, il gruppo può essere systemd-journal oppure root (entrambi sono normali).

2. Verificate che journald sia in esecuzione:

   sudo systemctl status systemd-journald

   Dovreste vedere che il servizio è nello stato active (running).

Risoluzione dei problemi

Se riscontrate problemi nella gestione dei log, controllate questi scenari comuni:

• Log del servizio vuoti (-- No entries --): Verificate che il servizio sia effettivamente installato e in esecuzione. Controllate inoltre di utilizzare il nome della unit corretto per la vostra distribuzione (ad esempio ssh su Debian/Ubuntu rispetto a sshd su RHEL/AlmaLinux).
• /var/log/journal mancante: Su alcuni sistemi (come AlmaLinux) è necessario creare manualmente questa directory e riavviare il servizio di logging per abilitare i log persistenti. Se si omette questo passaggio, i log rimarranno nella memoria volatile (/run/log/journal).
• Permesso negato (Permission denied): Se non riuscite a leggere i log senza sudo, verificate che il vostro utente appartenga al gruppo systemd-journal o adm (sudo usermod -aG systemd-journal $USER).

Ripristino delle modifiche

Se desiderate disattivare la registrazione persistente e tornare ai log volatili (ad esempio per risparmiare spazio su disco):

1. Rimuovete la directory di archiviazione persistente:

   sudo rm -rf /var/log/journal

2. Riavviate il servizio di logging per ricreare l'archiviazione volatile in /run/log/journal:

   sudo systemctl restart systemd-journald

Conclusione

È tutto. Ora conoscete gli elementi essenziali della gestione dei log in Linux. Con i giusti comandi journalctl potete navigare in modo efficiente tra i log di systemd, applicare filtri e gestire lo spazio su disco. Che dobbiate analizzare i log con journalctl dopo un crash o semplicemente verificare lo stato di un servizio, padroneggiare journalctl è un passo fondamentale per mantenere un'infrastruttura in salute.

Versione del documento: 1.0
Ultimo aggiornamento: maggio 2026
Responsabile: Team di documentazione tecnica