systemd (Italiano)/Journal (Italiano) - ArchWiki

Jump to content

# systemd (Italiano)/Journal (Italiano)

From ArchWiki
< Systemd (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-notificationAUR 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.

Category:

- Logging (Italiano)

systemd (Italiano)/Journal (Italiano)
Add topic