systemd (Italiano)/Journal (Italiano)

Stato della traduzioneQuesto articolo è la versione tradotta di Systemd/Journal. Data dell'ultima traduzione: 2026-02-14. Se ci sono cambiamenti nella versione inglese, è possibile dare una mano a sincronizzarne la traduzione.

systemd ha il proprio sistema di logging chiamato journal; l'esecuzione di un demone di logging separato non è richiesta. Per leggere i log si usa journalctl(1).

In Arch Linux la directory /var/log/journal/ fa parte del pacchetto systemd e il journal (quando Storage= è impostato su auto in /etc/systemd/journald.conf) scriverà in /var/log/journal/. Se tale directory viene eliminata, systemd non la ricreerà automaticamente e scriverà invece i propri log in /run/log/journal/ in modo non persistente. Tuttavia, la directory verrà ricreata se si aggiunge Storage=persistent a journald.conf e si riavvia systemd-journald.service (o si riavvia il sistema).

Il journal di systemd classifica i messaggi per Livello di priorità e Facility. La classificazione del logging corrisponde al protocollo Syslog classico (RFC 5424).

Livello di priorità

Un codice di severità di syslog (chiamato priority in systemd) viene utilizzato per marcare l'importanza di un messaggio RFC 5424 6.2.1.

Valore	Severità	Keyword	Descrizione	Esempi
0	Emergency	emerg	Il sistema è inutilizzabile	Grave BUG del kernel, systemd ha generato un core dump. Questo livello non dovrebbe essere usato dalle applicazioni.
1	Alert	alert	Deve essere corretto immediatamente	Sottosistema vitale fuori servizio. Perdita di dati. `kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc`.
2	Critical	crit	Condizioni critiche	Crash, coredump. Come il tipico messaggio: `systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core` Fallimento dell'applicazione primaria del sistema, come X11.
3	Error	err	Condizioni di errore	Segnalazione di errore non fatale: `kernel: usb 1-3: 3:1: cannot get freq at ep 0x84`, `systemd[1]: Failed unmounting /var.`, `libvirtd[1720]: internal error: Failed to initialize a valid firewall backend`
4	Warning	warning	Può indicare che si verificherà un errore se non si interviene	Un file system non-root ha solo 1GB libero. `org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale`
5	Notice	notice	Eventi insoliti, ma non condizioni di errore	`systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway`, `gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged`
6	Informational	info	Messaggi operativi normali che non richiedono azione	`lvm[585]: 7 logical volume(s) in volume group "archvg" now active`
7	Debug	debug	Messaggi che potrebbero dover essere prima abilitati, utili solo per il debug	`kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen"`

Queste regole sono raccomandazioni e il livello di priorità di un dato errore è a discrezione dello sviluppatore dell'applicazione. È sempre possibile che l'errore sia a un livello superiore o inferiore rispetto a quello previsto.

Facility

Un codice facility di syslog viene utilizzato per specificare il tipo di programma che sta registrando il messaggio RFC 5424 6.2.1.

Codice Facility	Keyword	Descrizione	Info
0	kern	Messaggi del kernel
1	user	Messaggi a livello utente
2	mail	Sistema di posta	POSIX arcaico ancora supportato e talvolta utilizzato (per maggiori info mail(1))
3	daemon	Demoni di sistema	Tutti i demoni, inclusi systemd e i suoi sottosistemi
4	auth	Messaggi di sicurezza/autorizzazione	Si veda anche la facility differente 10
5	syslog	Messaggi generati internamente da syslogd	Per implementazioni syslogd (non usato da systemd, si veda facility 3)
6	lpr	Sottosistema stampanti (arcaico)
7	news	Sottosistema network news (arcaico)
8	uucp	Sottosistema UUCP (arcaico)
9		Demone dell'orologio	systemd-timesyncd
10	authpriv	Messaggi di sicurezza/autorizzazione	Si veda anche la facility differente 4
11	ftp	Demone FTP
12	-	Sottosistema NTP
13	-	Log di audit
14	-	Log di allerta
15	cron	Demone di pianificazione
16	local0	Uso locale 0 (local0)
17	local1	Uso locale 1 (local1)
18	local2	Uso locale 2 (local2)
19	local3	Uso locale 3 (local3)
20	local4	Uso locale 4 (local4)
21	local5	Uso locale 5 (local5)
22	local6	Uso locale 6 (local6)
23	local7	Uso locale 7 (local7)

Facility utili da monitorare: 0, 1, 3, 4, 9, 10, 15.

Filtrare l'output

journalctl permette di filtrare l'output per campi specifici. Se ci sono molti messaggi da visualizzare o se deve essere eseguito il filtraggio di ampi intervalli temporali, l'output di questo comando può subire ritardi considerevoli.

Esempi:

Mostra tutti i messaggi che corrispondono al MODELLO:
```
# journalctl --grep=MODELLO
```
Mostra tutti i messaggi di questo avvio:
```
# journalctl -b
```
Spesso si è interessati ai messaggi non dell'avvio corrente, ma di quello precedente (ad esempio, se si è verificato un crash irreversibile del sistema). Ciò è possibile tramite il parametro opzionale di offset del flag -b: journalctl -b -0 mostra i messaggi dell'avvio corrente, journalctl -b -1 del precedente, journalctl -b -2 di due avvii fa e così via. È possibile vedere l'elenco degli avvii con i relativi numeri usando journalctl --list-boots. Si veda journalctl(1) per una descrizione completa; la semantica è più potente di quanto indicato qui.
Include spiegazioni dei messaggi dai cataloghi, dove disponibili:
```
# journalctl -x
```
Si noti che questa funzione non dovrebbe essere usata quando si allegano log a segnalazioni di bug o thread di supporto, per limitare l'output superfluo. È possibile elencare tutte le voci del catalogo note eseguendo journalctl --list-catalog.
Mostra tutti i messaggi da una data (e ora opzionale):
```
# journalctl --since="2012-10-30 18:17:16"
```
Mostra tutti i messaggi degli ultimi 20 minuti:
```
# journalctl --since "20 min ago"
```
Segue i nuovi messaggi in tempo reale:
```
# journalctl -f
```
Mostra tutti i messaggi di un eseguibile specifico:
```
# journalctl /usr/lib/systemd/systemd
```
Mostra tutti i messaggi di un identificatore specifico:
```
# journalctl -t sudo
```
Mostra tutti i messaggi di un processo specifico:
```
# journalctl _PID=1
```
Mostra tutti i messaggi di una specifica unità:
```
# journalctl -u man-db.service
```
Mostra tutti i messaggi dai servizi utente di una specifica unità:
```
$ journalctl --user -u dbus
```
Mostra il buffer ad anello del kernel:
```
# journalctl -k
```
Mostra solo i messaggi di priorità error, critical e alert:
```
# journalctl -p err..alert
```
È possibile utilizzare anche il livello log numerico, come journalctl -p 3..1. Se viene utilizzato un singolo numero/livello log, journalctl -p 3, vengono inclusi anche tutti i livelli log a priorità superiore (cioè da 0 a 3 in questo caso).
Mostra l'equivalente di auth.log filtrando per facility syslog:
```
# journalctl SYSLOG_FACILITY=10
```
Se la directory del journal (per impostazione predefinita situata in /var/log/journal) contiene una grande quantità di dati, journalctl può richiedere diversi minuti per filtrare l'output. Può essere velocizzato significativamente usando l'opzione --file per forzare journalctl a guardare solo nel journal più recente:
```
# journalctl --file /var/log/journal/*/system.journal -f
```

Si veda journalctl(1), systemd.journal-fields(7), o il post sul blog di Lennart Poettering per i dettagli.

Suggerimento

Per impostazione predefinita, journalctl tronca le righe più lunghe della larghezza dello schermo, ma in alcuni casi può essere preferibile abilitare l'andata a capo (wrapping) invece del troncamento. Ciò può essere controllato dalla variabile d'ambiente SYSTEMD_LESS, che contiene le opzioni passate a less (il pager predefinito) e ha come valore predefinito FRSXMK (si vedano less(1) e journalctl(1) per i dettagli).

Omettendo l'opzione S, l'output andrà a capo invece di essere troncato. Ad esempio, si avvii journalctl come segue:

$ SYSTEMD_LESS=FRXMK journalctl

Per impostare questo comportamento come predefinito, si effettui l'export della variabile in ~/.bashrc o ~/.zshrc.

Sebbene il journal sia memorizzato in formato binario, il contenuto dei messaggi memorizzati non viene modificato. Ciò significa che è visualizzabile con strings, ad esempio per il recupero in un ambiente che non ha systemd installato:
```
$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i messaggio
```

Suggerimenti e trucchi

Limite di dimensione del journal

Se il journal è persistente (non volatile), il suo limite di dimensione è impostato a un valore predefinito del 10% della dimensione del file system sottostante, ma con un tetto massimo di 4 GiB. Ad esempio, con /var/log/journal/ situato su una partizione da 20 GiB, i dati del journal possono occupare fino a 2 GiB. Su una partizione da 50 GiB, il massimo sarebbe 4 GiB. Per confermare i limiti attuali sul proprio sistema, si consultino i log dell'unità systemd-journald:

# journalctl -b -u systemd-journald

La dimensione massima del journal persistente può essere controllata decommentando e modificando quanto segue:

/etc/systemd/journald.conf

SystemMaxUse=50M

Nota Se SystemMaxUse è impostato su un valore elevato (per scopi di risoluzione dei problemi, ad esempio), potrebbe essere comunque limitato dal parametro predefinito SystemKeepFree, che è impostato al 15% del filesystem sottostante. Il demone del journal rispetterà entrambi i parametri e utilizzerà il minore tra i due.

È anche possibile utilizzare il meccanismo di override della configurazione tramite snippet drop-in invece di modificare il file di configurazione globale. In questo caso, si inseriscano gli override sotto l'intestazione [Journal]:

/etc/systemd/journald.conf.d/00-journal-size.conf

[Journal]
SystemMaxUse=50M

Riavviare systemd-journald.service dopo aver modificato questa impostazione per applicare il nuovo limite.

Si veda journald.conf(5) per ulteriori informazioni.

Limite di dimensione per unità tramite namespace del journal

Modificare il file unit per il servizio che si desidera configurare (ad esempio sshd) e aggiungere LogNamespace=ssh nella sezione [Service].

Quindi creare /etc/systemd/journald@ssh.conf copiando /etc/systemd/journald.conf. Successivamente, modificare journald@ssh.conf e regolare SystemMaxUse a proprio piacimento.

Il riavvio del servizio dovrebbe avviare automaticamente il nuovo servizio journal systemd-journald@ssh.service. I log del servizio nel relativo namespace possono essere visualizzati con journalctl --namespace ssh.

Si veda systemd-journald.service(8) § JOURNAL NAMESPACES per dettagli sui namespace del journal.

Pulire manualmente i file del journal

I file del journal possono essere rimossi globalmente da /var/log/journal/ usando ad esempio rm, oppure possono essere sfoltiti secondo vari criteri usando journalctl. Per esempio:

Rimuove i file del journal archiviati finché lo spazio su disco che utilizzano non scende sotto i 100M:
```
# journalctl --vacuum-size=100M
```
Fa sì che tutti i file del journal non contengano dati più vecchi di 2 settimane:
```
# journalctl --vacuum-time=2weeks
```

I file del journal devono essere stati ruotati (rotated) e resi inattivi prima di poter essere sfoltiti dai comandi vacuum. La rotazione dei file del journal può essere eseguita eseguendo journalctl --rotate. L'argomento --rotate può anche essere fornito insieme a uno o più argomenti di criteri vacuum per eseguire la rotazione e poi sfoltire i file in un unico comando.

Si veda journalctl(1) per ulteriori informazioni.

Journald in combinazione con syslog

La compatibilità con un'implementazione syslog classica e non compatibile con il journal può essere fornita lasciando che systemd inoltri tutti i messaggi tramite il socket /run/systemd/journal/syslog. Per far funzionare il demone syslog con il journal, questo deve legarsi a questo socket invece di /dev/log (annuncio ufficiale).

Il valore predefinito di journald.conf per l'inoltro al socket è ForwardToSyslog=no per evitare sovraccarico del sistema, poiché rsyslog o syslog-ng prelevano i messaggi dal journal autonomamente.

Si veda Syslog-ng#Overview e Syslog-ng#syslog-ng and systemd journal, o rispettivamente rsyslog, per i dettagli sulla configurazione.

Inoltrare journald a /dev/tty12

Creare una directory drop-in /etc/systemd/journald.conf.d e creare un file fw-tty12.conf al suo interno:

/etc/systemd/journald.conf.d/fw-tty12.conf

[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12

Quindi riavviare systemd-journald.service.

Nota Per progettazione questo non inoltra i messaggi di log del kernel ring buffer.

Specificare un journal diverso da visualizzare

Potrebbe esserci la necessità di controllare i log di un altro sistema che è bloccato, come nel caso dell'avvio da un sistema live per ripristinare un sistema di produzione. In tal caso, si può montare il disco in ad esempio /mnt e specificare il percorso del journal tramite -D oppure --directory, in questo modo:

# journalctl -D /mnt/var/log/journal -e

Accesso al journal come utente

Per impostazione predefinita, un utente regolare ha accesso solo al proprio journal personale. Per concedere l'accesso in lettura al journal di sistema come utente normale, è possibile aggiungere quell'utente al gruppo utenti systemd-journal. Anche ai membri dei gruppi adm e wheel viene concesso l'accesso in lettura.

Si vedano journalctl(1) § DESCRIPTION e Utenti e gruppi#Gruppi utente per ulteriori informazioni.

Notifiche desktop

Le notifiche desktop possono aiutare a notare rapidamente i messaggi di errore, migliorando la consapevolezza rispetto al controllo manuale dei log o al non notarli affatto.

Il pacchetto journalctl-desktop-notification^AUR fornisce una notifica desktop automatica per ogni messaggio di errore registrato da qualsiasi processo. Per maggiori dettagli e opzioni di configurazione, si visiti la pagina del progetto su GitLab.