Comando journalctl: uso, log per servizio e pulizia delle dimensioni del journal

Il comando journalctl è lo strumento per scegliere e leggere, nel journal di systemd, i log lasciati dai servizi e dal kernel. Su Linux con systemd, systemd-journald raccoglie questi log nel journal. Leggendo i log per servizio, orario e priorità su un server AlmaLinux 9 e su un server Debian 12, un account normale vedeva solo i propri log, e un server che tiene il journal in memoria non poteva scegliere un avvio precedente.

L'output qui sotto proviene dai due server. Nomi host, account, ID di avvio, numeri di processo del server AlmaLinux e la release del pacchetto systemd sono stati sostituiti con valori di esempio, ed entrambi i server hanno stampato gli orari in UTC.

1️⃣ Come usare il comando journalctl e leggere i log recenti

Se esegui journalctl senza opzioni, il journal si apre in less dalla riga più vecchia; per vedere i log recenti imposta quindi il numero di righe con -n. Se ometti il numero dopo -n, compaiono 10 righe.

journalctl -n 3

Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Deactivated successfully.
Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Consumed 3.934s CPU time.
Oct 28 07:14:07 server1 sudo[851987]: pam_unix(sudo:session): session closed for user user

Ogni riga è composta da orario, nome host, programma che ha scritto il log con il suo numero di processo e messaggio. Con -r l'ordine si inverte e la riga più recente sale in cima. Nel log di crond del server AlmaLinux, la riga CMDEND scritta per ultima era in cima.

journalctl -r -u crond -n 3

Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-f non termina dopo l'ultima riga e continua a stampare le nuove righe man mano che arrivano. Sul server Debian 12 l'ultima riga di logger è rimasta a schermo con -q e -t myapp, e con logger sono state scritte altre due righe. Le due righe sono comparse subito sotto.

journalctl -q -f -n 1 -t myapp

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test
Oct 28 07:14:35 server2 myapp[347881]: follow line 1
Oct 28 07:14:36 server2 myapp[347877]: follow line 2

-f non si ferma finché non premi Ctrl+C, quindi usalo per seguire il log mentre un servizio si riavvia.

In less, le righe più larghe dello schermo vengono tagliate a destra e la parte tagliata si vede con i tasti freccia. L'output inviato a una pipe o a un file non passa da less. Per stampare direttamente nel terminale senza less, aggiungi --no-pager.

2️⃣ Log di journalctl per servizio

Le righe recenti mescolano i log di molti servizi; per vedere il log di un solo servizio indica quindi il nome dell'unità con -u. Il .service alla fine del nome dell'unità si può omettere.

journalctl -u crond -n 4

Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

Scrivendo -u due volte, i log dei due servizi escono mescolati in ordine di orario. Selezionando insieme crond e nginx dalle 08:00 alle 08:15 del 18 ottobre sul server AlmaLinux, dopo quattro righe di crond alle 08:01 sono seguite due righe di nginx reload alle 08:12.

journalctl -u nginx -u crond --since '2026-10-18 08:00' --until '2026-10-18 08:15'

Oct 18 08:01:01 server1 CROND[381522]: (root) CMD (run-parts /etc/cron.hourly)
Oct 18 08:01:01 server1 run-parts[381528]: (/etc/cron.hourly) starting 0anacron
Oct 18 08:01:01 server1 run-parts[381534]: (/etc/cron.hourly) finished 0anacron
Oct 18 08:01:01 server1 CROND[381518]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 18 08:12:30 server1 systemd[1]: Reloading nginx - high performance web server...
Oct 18 08:12:30 server1 systemd[1]: Reloaded nginx - high performance web server.

systemctl status mostra solo le ultime 10 righe di log sotto lo stato del servizio, quindi i log precedenti si controllano con journalctl -u. Subito dopo aver eseguito systemctl restart su un servizio, esegui journalctl -u per controllare il log di avvio.

I log che script o job di cron hanno scritto con logger si trovano tramite l'etichetta (identificatore), non tramite un'unità. Dopo -t scrivi lo stesso nome dato al -t di logger.

logger -t myapp 'journalctl test message'

Sul server Debian 12 logger non ha stampato nulla a schermo, e le righe scritte sono state trovate con -t myapp.

journalctl -q -t myapp

Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

-g lascia solo le righe il cui messaggio contiene un certo testo. Se scrivi il testo tutto in minuscolo, maiuscole e minuscole non vengono distinte.

journalctl -u crond -g anacron -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron

-n conta le righe prima che -g le filtri, quindi delle ultime due righe di crond è rimasta solo quella con anacron.

3️⃣ Log per intervallo di tempo e per avvio

--since e --until fissano l'inizio e la fine dell'intervallo di tempo stampato. Se tra data e ora c'è uno spazio, racchiudi il valore tra virgolette singole.

Sul server AlmaLinux le ultime 2 ore iniziavano con le righe di crond scritte alle 06:01; qui sotto ci sono le prime quattro.

journalctl -u crond --since '-2h' | head -4

Oct 28 06:01:01 server1 CROND[802930]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 06:01:01 server1 run-parts[802936]: (/etc/cron.hourly) starting 0anacron
Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-b lascia solo i log dall'avvio corrente. Se cerchi perché un server si è riavviato, controlla prima nell'elenco degli avvii se restano i log dell'avvio precedente.

journalctl -b -u crond -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

--list-boots stampa, per ogni avvio rimasto nel journal, il numero, l'ID di avvio e l'orario della prima e dell'ultima riga.

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 4f1c2a9be0d34c7a8e6b5d20c1f3a7e9 Sat 2026-10-17 08:29:26 UTC Wed 2026-10-28 07:16:10 UTC

Il server AlmaLinux non tiene il journal su disco e aveva quindi un solo record di avvio. Per questo -b -1 per l'avvio precedente ha lasciato solo un avviso e si è chiuso.

journalctl -b -1

Specifying boot ID or boot offset has no effect, no persistent journal was found.

I log di un avvio precedente si leggono con -b -1 solo sui server che salvano il journal su disco (/var/log/journal).

4️⃣ Log degli errori e log del kernel con journalctl

-p seleziona le righe in base alla priorità del log. Indicando un livello compaiono quel livello e tutti quelli più importanti, e il livello si può scrivere sia come nome sia come numero.

Dopo aver scritto una riga di livello err con logger e selezionato con -p err, la riga di livello notice con la stessa etichetta (journalctl test message) è sparita ed è rimasta solo la riga err.

logger -t myapp -p user.err 'journalctl error test'; journalctl -q -t myapp -p err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

Collegando due livelli con due punti si stampa solo quell'intervallo. Con warning..err restano solo i livelli avviso ed errore.

journalctl -q -t myapp -p warning..err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

-k lascia solo i messaggi del kernel e stampa solo le righe dall'avvio corrente.

journalctl -k -n 3

Oct 26 10:14:25 server1 systemd-rc-local-generator[96245]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 10:47:57 server1 systemd-rc-local-generator[512078]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 11:01:10 server1 systemd-rc-local-generator[520023]: /etc/rc.d/rc.local is not marked executable, skipping.

Le ultime tre righe di -k sul server AlmaLinux erano tutte righe di systemd-rc-local-generator. Sono messaggi scritti nel buffer di log del kernel, quindi vengono salvati con _TRANSPORT uguale a kernel e compaiono anche con -k.

5️⃣ Formati di output di journalctl

-o cambia il formato di ogni riga. Il valore predefinito short è quasi uguale a un file syslog, mentre short-iso porta l'orario nel formato ISO 8601 con il fuso orario. Passando a short-iso sul server AlmaLinux, alla fine dell'orario si è aggiunto +0000.

journalctl -u crond -n 2 -o short-iso

2026-10-28T07:01:01+0000 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
2026-10-28T07:01:01+0000 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

cat toglie orario e nome host e stampa solo il messaggio; usalo quando passi i messaggi a grep o a un altro programma.

journalctl -u crond -n 2 -o cat

(/etc/cron.hourly) starting 0anacron
(root) CMDEND (run-parts /etc/cron.hourly)

json e json-pretty stampano i campi salvati nel journal come nomi e valori. Quando scegli i campi con --output-fields, i campi di cursore, orario e ID di avvio arrivano sempre insieme. Anche scegliendo solo quattro campi sul server Debian 12, sono comparsi insieme __CURSOR, _BOOT_ID e due campi di orario.

journalctl -q -t myapp -n 1 -o json-pretty --output-fields=MESSAGE,PRIORITY,SYSLOG_IDENTIFIER,_PID

{
	"__REALTIME_TIMESTAMP" : "1793171676664200",
	"_PID" : "347877",
	"SYSLOG_IDENTIFIER" : "myapp",
	"MESSAGE" : "follow line 2",
	"__CURSOR" : "s=2a6f0c1d9e8b47a3b5c4d3e2f1a0b9c8;i=1a2b3;b=b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47;m=17cf8fe36f5;t=65ee150cf1188;x=1f2e3d4c5b6a7980",
	"_BOOT_ID" : "b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47",
	"PRIORITY" : "5",
	"__MONOTONIC_TIMESTAMP" : "1636264982261"
}

6️⃣ Posizione del journal e pulizia delle dimensioni

Se il journal sta in memoria o su disco lo decide il valore Storage= di journald.conf. Il valore predefinito auto salva su disco se esiste la cartella /var/log/journal, altrimenti in memoria (/run/log/journal).

Il server AlmaLinux non aveva la cartella /var/log/journal, quindi il journal era solo in /run/log/journal.

ls -ld /var/log/journal /run/log/journal

ls: cannot access '/var/log/journal': No such file or directory
drwxr-sr-x+ 4 root systemd-journal 80 Oct 17 08:30 /run/log/journal

Il server Debian 12 aveva entrambe le cartelle, e il journal si accumulava su disco.

ls -ld /var/log/journal /run/log/journal

drwxr-sr-x+ 2 root systemd-journal   40 Oct  9 08:43 /run/log/journal
drwxr-sr-x+ 4 root systemd-journal 4096 Sep 24 12:52 /var/log/journal

Per conservare i log dopo un riavvio, imposta Storage= su persistent in journald.conf e riavvia systemd-journald. Secondo il manuale ufficiale, la cartella /var/log/journal viene creata automaticamente quando serve. Per questo articolo le impostazioni non sono state cambiate.

Un journal salvato su disco è come la scatola nera di un aereo, che si recupera e si legge dopo un incidente.

--disk-usage stampa la dimensione totale dei file del journal archiviati e di quelli in uso. Su un account normale del server Debian 12, con l'avviso [Hint] in alto nascosto da -q, il risultato era una sola riga: 6.6M.

journalctl -q --disk-usage

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

La dimensione massima del journal salvato su disco si imposta con SystemMaxUse=. Senza valore, il limite è il 10% della dimensione del file system (al massimo 4G), e nel journald.conf del server Debian 12 c'era scritto 50M.

grep -v '^#' /etc/systemd/journald.conf | grep -v '^$'

[Journal]
SystemMaxUse=50M

Per ridurre subito i journal vecchi, imposta la dimensione da tenere con --vacuum-size o il periodo da tenere con --vacuum-time. Entrambi i comandi eliminano file del journal, quindi in questo articolo non sono stati eseguiti.

journalctl --vacuum-size=200M

--vacuum-size=200M elimina i file del journal archiviati, a partire dai più vecchi, finché la dimensione totale scende sotto 200M.

journalctl --vacuum-time=2weeks

--vacuum-time=2weeks elimina i file di archivio che contengono solo righe più vecchie di 2 settimane.

vacuum elimina solo i file archiviati e lascia quelli in uso, quindi anche dopo averlo eseguito il numero di --disk-usage potrebbe non scendere fino alla dimensione indicata.

I log di testo in /var/log li scrive rsyslog, che funziona separatamente da journald. Per questo i due log si leggono e si gestiscono in modo diverso.

7️⃣ Permessi di lettura e opzioni del comando journalctl

🔲 Permessi di lettura

Eseguendo journalctl con un account diverso da root, in alto compare un testo [Hint] e si vedono solo i log scritti da quell'account. Cercando i log di nginx con un account normale sul server Debian 12, dopo l'avviso è comparso solo [-- No entries --].

journalctl -u nginx -n 5

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --

Secondo id -nG, questo account apparteneva a un solo gruppo e non era nei gruppi adm o systemd-journal citati dall'avviso.

id -nG

user

Il manuale ufficiale spiega che gli account dei gruppi systemd-journal, adm e wheel possono leggere tutto il journal. adm e wheel portano altri permessi stabiliti dalla distribuzione, e wheel spesso consente anche attività di amministrazione, quindi per un account che legge solo i log il gruppo giusto è systemd-journal.

usermod -aG systemd-journal user

Il comando usermod che aggiunge il gruppo non è stato eseguito in questo articolo. Dopo aver aggiunto il gruppo, accedi di nuovo e controlla i gruppi con id -nG. Un account con permessi di amministratore vede tutti i log anche eseguendo sudo journalctl.

Il testo [Hint] si nasconde con -q. Anche con -q, però, i log visibili restano solo le righe scritte da quell'account. --user legge il journal utente di quell'account e funziona solo sui server che salvano il journal su disco. Sul server Debian 12, che tiene il journal su disco, sono comparse le righe di systemd e di logger di quell'account.

journalctl --user -n 3

Oct 28 07:12:35 server2 systemd[347665]: Reached target default.target - Main User Target.
Oct 28 07:12:35 server2 systemd[347665]: Startup finished in 181ms.
Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

🔲 Opzioni del comando journalctl

📌 Opzioni principali: risultati di questo articolo

📎 Altre opzioni: secondo il manuale ufficiale

🔲 Simulatore del comando journalctl

Nel simulatore qui sotto puoi digitare tu i comandi per controllare log recenti, log per servizio, intervalli di tempo, priorità e formati di output.

🔢 FAQ & contenuti consigliati

🧭 Comandi per info · impostazioni di sistema: contenuti consigliati 8 articoli · 2 riferimenti

🗂️ Comandi per info · impostazioni di sistema

▸📂 Info di sistema4

📄 Info su CPU · RAM · disco · OS 📄 uname · versione del kernel 📄 Comando free 📄 Comando uptime

▸📂 Impostazioni2

📄 Comando timedatectl 📄 Comando localectl

▸📂 Log2

📄 logrotate 📄 Comando journalctl

▸🪐 Riferimenti2

📡 journalctl(1) — systemd 252 📡 journald.conf(5) — systemd 252

Linux · Info di sistema

Controllare la CPU in Linux: comandi per RAM, disco e informazioni sul sistema operativo

Su Linux il numero di core della CPU si ottiene subito con una riga: [nproc].

Leggi l'articolo →Contenuto attuale

Linux · Info di sistema

Comandi per controllare la versione del kernel Linux e come controllare la versione della distribuzione

Quando si gestisce Linux, a volte bisogna controllare la versione del kernel Linux e la versione della distribuzione.

Leggi l'articolo →Contenuto attuale

Linux · Info di sistema

Comando free di Linux: controllare lo stato della memoria

Il comando free di Linux mostra l'uso della memoria e la memoria libera del server leggendo le informazioni da /proc/meminfo.

Leggi l'articolo →Contenuto attuale

Linux · Info di sistema

Comando uptime di Linux (tempo di attività del server & carico medio a 1, 5 e 15 minuti)

Il comando uptime di Linux mostra il carico medio del sistema e da quanto tempo il server è acceso.

Leggi l'articolo →Contenuto attuale

Linux · Impostazioni

Sincronizzare l'ora del server Linux: timedatectl (CentOS 7 e successivi)

Su Linux data e ora vanno impostate perché, se l'ora è sbagliata mentre il server lavora, gli orari dei dati del DB, dei log e degli accessi al server web possono non coincidere.

Leggi l'articolo →Contenuto attuale

Linux · Impostazioni

[Linux] Comando localectl

Da CentOS 7 molti comandi sono forniti in forma integrata.

Leggi l'articolo →Contenuto attuale

Linux · Log

Logrotate su Linux: concetto e impostazioni

Logrotate di Linux, come suggerisce l'espressione "ruotare i log", è l'unione di log e rotate.

Leggi l'articolo →Contenuto attuale

Linux · Log

Comando journalctl: uso, log per servizio e pulizia delle dimensioni del journal

Il comando journalctl è lo strumento per scegliere e leggere, nel journal di systemd, i log lasciati dai servizi e dal kernel, e su Linux con systemd systemd-journald raccoglie questi log nel journal.

Leggi l'articolo →Contenuto attuale

📡journalctl(1) — systemd 252 📡journald.conf(5) — systemd 252

ℹ️ Informativa sull'affiliazione
I contenuti di questo sito includono link di affiliazione. Se un visitatore acquista un prodotto o un servizio tramite uno di questi link, il sito riceve una commissione dal venditore. In questo processo l'importo pagato dall'acquirente ^{(durante le promozioni l'importo scende↓)} non aumenta. Prezzi, sconti e disponibilità indicati si riferiscono al momento della stesura e possono differire da quelli reali: prima di acquistare verifica sempre presso il venditore. I prodotti vengono scelti e valutati secondo criteri propri, e le commissioni non influiscono sull'ordine di presentazione né sul contenuto delle valutazioni.