Come limitare temporalmente i log nel journal di systemd e avere journalctl più reattivo

[Davide Prina]

mi sono accorto che non ho tantissimo spazio libero su /
e indagando ho scoperto che il journal di systemd stava occupando
diversi giga. Ho scoperto che al massimo, come impostazioni di default,
dovrebbe occupare 4 GByte.

Per vedere quanto spazio sta occupando attualmente:
$ journalctl --disk-usage

ho visto che i log partivano da diversi mesi fa e avevo già notato che
la consultazione del journal era sempre più lenta.

Visto che a me non interessa avere un journal che può andare indietro
così tanto ho modificato il file /etc/systemd/journald.conf e ho tolto
il commento alla variabile MaxRetentionSec impostandola a max 2 mesi:
MaxRetentionSec=2month

poi ho riavviato il journal per eliminare tutti i log oltre i due mesi:
# systemctl restart systemd-journald.service

ora se voglio vedere il log attuale
$ journalctl -b 0

ho la risposta completa immediatamente :-)

e ho liberato un po' di spazio (circa 2 GByte), non molto, ma è già
qualcosa.

Se qualcuno vuole indagare ulteriormente è possibile leggere il man
$ man 5 journald.conf

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
$
Perché microsoft continua a compiere azioni illegali?:
http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

[Alessandro Baggi]

On 30/10/21 10:48, Davide Prina wrote:
> mi sono accorto che non ho tantissimo spazio libero su /
> e indagando ho scoperto che il journal di systemd stava occupando
> diversi giga. Ho scoperto che al massimo, come impostazioni di
> default, dovrebbe occupare 4 GByte.
>
> Per vedere quanto spazio sta occupando attualmente:
> $ journalctl --disk-usage
>
> ho visto che i log partivano da diversi mesi fa e avevo già notato che
> la consultazione del journal era sempre più lenta.
>
> Visto che a me non interessa avere un journal che può andare indietro
> così tanto ho modificato il file /etc/systemd/journald.conf e ho tolto
> il commento alla variabile MaxRetentionSec impostandola a max 2 mesi:
> MaxRetentionSec=2month
>
> poi ho riavviato il journal per eliminare tutti i log oltre i due mesi:
> # systemctl restart systemd-journald.service
>
> ora se voglio vedere il log attuale
> $ journalctl -b 0
>
> ho la risposta completa immediatamente :-)
>
> e ho liberato un po' di spazio (circa 2 GByte), non molto, ma è già
> qualcosa.
>
> Se qualcuno vuole indagare ulteriormente è possibile leggere il man
> $ man 5 journald.conf
>
> Ciao
> Davide
>

Ciao Davide,

grazie per la condivisione.

[pinguino]

On 30/10/21 10:48, Davide Prina wrote:

> mi sono accorto che non ho tantissimo spazio libero su /
> e indagando ho scoperto che il journal di systemd stava occupando
> diversi giga. Ho scoperto che al massimo, come impostazioni di default,
> dovrebbe occupare 4 GByte.
>
> Per vedere quanto spazio sta occupando attualmente:
> $ journalctl --disk-usage
>
> ho visto che i log partivano da diversi mesi fa e avevo già notato che
> la consultazione del journal era sempre più lenta.
>
> Visto che a me non interessa avere un journal che può andare indietro
> così tanto ho modificato il file /etc/systemd/journald.conf e ho tolto
> il commento alla variabile MaxRetentionSec impostandola a max 2 mesi:
> MaxRetentionSec=2month
>
> poi ho riavviato il journal per eliminare tutti i log oltre i due mesi:
> # systemctl restart systemd-journald.service
>
> ora se voglio vedere il log attuale
> $ journalctl -b 0
>
> ho la risposta completa immediatamente :-)
>
> e ho liberato un po' di spazio (circa 2 GByte), non molto, ma è già
> qualcosa.
>
> Se qualcuno vuole indagare ulteriormente è possibile leggere il man
> $ man 5 journald.conf
>
> Ciao
> Davide
>

Buongiorno Lista,
Ho aggiornato anche io il journald.conf.
Mi sembra meglio risparmiare un po di spazio sul disco A.

Infatti ho un problema sul disco B. La partizione di Root (da 20 GB)
risulta piena. Ma se vado a vedere con l'analizzatore di spazio disco,
risultano solo 6 GB di spazio usato.
Forse c'è qualcosa che mi occupa spazio ma non lo trovo. Saranno i files
di log del journald ?
Ho anche guardato i files nascosti ma non c'è nulla che occupa tanto
spazio.

Grazie
Ciao

--
https://www.linkedin.com/in/claudio-sandrone

[Alessandro Rubini]

> Infatti ho un problema sul disco B. La partizione di Root (da 20 GB)
> risulta piena. Ma se vado a vedere con l'analizzatore di spazio disco,
> risultano solo 6 GB di spazio usato.

Cos'e` questo "analizzatore di spazio disco"?

Io faccio "du -x / | sort -n". Ovviamente da amministratore, perche`
alcune directory non sono leggibili come utente, e se lo spazio
occupato e` li` non lo si vedrebbe (ma ci sarebbero dei "permission denied"
durante la scansione).

Utile anche, magari prima de "du", un "df -h" e "df -i" per vedere
se e` davvero piena, e se non lo e` se per caso non sono finiti gli
inode (cioe` ci sono troppi file).

saluti
/alessandro

[Paolo Redaelli]

Il 31/10/21 12:59, Alessandro Rubini ha scritto:

>> Infatti ho un problema sul disco B. La partizione di Root (da 20 GB)
>> risulta piena. Ma se vado a vedere con l'analizzatore di spazio disco,
>> risultano solo 6 GB di spazio usato.
> Cos'e` questo "analizzatore di spazio disco"?

Probabilmente si riferisce a Baobab per Gnome (qui
https://wiki.gnome.org/action/show/Apps/DiskUsageAnalyzer )

Gnome è bellissimo, ma dalla versione 3 ha iniziato questa bruttissima
abitudine di non mostrare da nessuna parte il nome "del progetto". Così
baobab è chiamato "Analizzatore di utilizzo del disco", Nautilus diventa
"File" ed altri che ora non ricordo...

[pinguino]

On 31/10/21 12:59, Alessandro Rubini wrote:
>> Infatti ho un problema sul disco B. La partizione di Root (da 20 GB)
>> risulta piena. Ma se vado a vedere con l'analizzatore di spazio disco,
>> risultano solo 6 GB di spazio usato.
>

Buongiorno Lista,

> Cos'e` questo "analizzatore di spazio disco"?

Un programma grafico di Mate, che analizza lo spazio disco e lo
rappresenta in forma grafica.

>
> Io faccio "du -x / | sort -n". Ovviamente da amministratore, perche`
> alcune directory non sono leggibili come utente, e se lo spazio
> occupato e` li` non lo si vedrebbe (ma ci sarebbero dei "permission denied"
> durante la scansione).

Probabilmente quel comando è simile a quello che usa l'analizzatore del
disco, ma in forma testuale sul terminale.

>
> Utile anche, magari prima de "du", un "df -h" e "df -i" per vedere
> se e` davvero piena, e se non lo e` se per caso non sono finiti gli
> inode (cioe` ci sono troppi file).

df -h
File system Dim. Usati Dispon. Uso% Montato su
udev 1,9G 0 1,9G 0% /dev
tmpfs 394M 1,2M 393M 1% /run
/dev/sdb1 20G 5,3G 13G 30% /
tmpfs 2,0G 992K 2,0G 1% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
/dev/sdb6 54G 40G 11G 79% /home
tmpfs 394M 72K 394M 1% /run/user/1001
/dev/sda1 20G 20G 0 100% /mnt

La partizione incriminata è sda1 ed è piena al 100 %, montata su /mnt.

df -i
File system Inode IUsati ILiberi IUso% Montato su
udev 490087 448 489639 1% /dev
tmpfs 503734 757 502977 1% /run
/dev/sdb1 1277952 191957 1085995 16% /
tmpfs 503734 30 503704 1% /dev/shm
tmpfs 503734 3 503731 1% /run/lock
/dev/sdb6 3596288 460185 3136103 13% /home
tmpfs 100746 82 100664 1% /run/user/1001
/dev/sda1 1343488 193387 1150101 15% /mnt

Sembra che gli inode siano ancora liberi. Risultano 1150101 su sda1,
sono usati solo al 15%.

Per questo ho dato un comando per scrivere nel file testo, perché nel
terminale non si leggeva tutto.
du -x / | sort -n > dux.txt

Allego solo gli ultimi, che sono i più grandi, con 6 e 7 cifre.

105336 /usr/lib/thunderbird
108824 /boot
111356 /usr/lib/gcc/x86_64-linux-gnu/10
111360 /usr/lib/gcc/x86_64-linux-gnu
111364 /usr/lib/gcc
117004 /usr/share/texlive/texmf-dist/tex/latex
144856 /var/lib/apt/lists
144984 /var/lib/apt
153516 /usr/share/texlive/texmf-dist/tex
161860 /usr/lib/modules/5.10.46-cs-20210919/kernel/drivers
195276 /usr/share/texlive/texmf-dist
197424 /usr/lib/chromium
199132 /usr/share/texlive
200144 /usr/lib/firefox-esr
201264 /usr/share/icons
208204 /usr/lib/modules/5.10.0-9-amd64/kernel/drivers
217060 /usr/share/doc
218072 /usr/lib/libreoffice/program
229920 /usr/lib/modules/5.10.46-cs-20210919/kernel
230980 /usr/bin
233956 /usr/lib/modules/5.10.46-cs-20210919
260988 /var/lib
270596 /usr/src
279376 /opt/google/chrome
279380 /opt/google
279384 /opt
294544 /usr/lib/libreoffice
295484 /usr/lib/modules/5.10.0-9-amd64/kernel
300428 /usr/lib/modules/5.10.0-9-amd64
364420 /var
534388 /usr/lib/modules
1015380 /usr/lib/x86_64-linux-gnu
1441784 /usr/share
2672796 /usr/lib
4748932 /usr
5513780 /

Se alcuni di quelli non sono utili o indispensabili al funzionamento del
sistema si possono cancellare ?

Grazie
Ciao
Claudio

>
> saluti
> /alessandro
>


--
https://www.linkedin.com/in/claudio-sandrone

[Marco Bodrato]

Il 2021-10-31 16:42 pinguino ha scritto:
> On 31/10/21 12:59, Alessandro Rubini wrote:
>> Io faccio "du -x / | sort -n". Ovviamente da amministratore, perche`

Intanto sottolineiamo che il suggerimento aveva una precisazione:
**Ovviamente da amministratore**

>> Utile anche, magari prima de "du", un "df -h" e "df -i" per vedere

> df -h
> File system Dim. Usati Dispon. Uso% Montato su

> /dev/sdb1 20G 5,3G 13G 30% /

> /dev/sdb6 54G 40G 11G 79% /home

> /dev/sda1 20G 20G 0 100% /mnt

Quindi, quella piena è sda1, montata su /mnt, ed è piena nel senso
dello spazio dati, non degli i-node.

> Per questo ho dato un comando per scrivere nel file testo, perché nel
> terminale non si leggeva tutto.
> du -x / | sort -n > dux.txt

Ma qui hai guardato lo spazio occupato nella partizione / ovverosia
nella partizione /dev/sdb1

> Allego solo gli ultimi, che sono i più grandi

... :-) che è lo scopo di aver inserito "sort -n" nel suggerimento :-D

Ti suggerisco, a questo punto, di vedere cosa succede con

du -hx /mnt/ | sort -h

Meglio come amministratore, per evitare che cartelle di utenti inattesi
possano rimanere fuori dal conto.

> 197424 /usr/lib/chromium
> 200144 /usr/lib/firefox-esr
> 279376 /opt/google/chrome

> Se alcuni di quelli non sono utili o indispensabili al funzionamento
> del
> sistema si possono cancellare ?

C'è chromium, c'è firefox... il software non libero chrome di certo non
è
indispensabile :-P

Ĝis,
m

[peterpunk]

On Sat, 30 Oct 2021 10:48:12 +0200 Davide wrote:

> mi sono accorto che non ho tantissimo spazio libero su /
> e indagando ho scoperto che il journal di systemd stava occupando
> diversi giga. Ho scoperto che al massimo, come impostazioni di
> default, dovrebbe occupare 4 GByte.
>
> Per vedere quanto spazio sta occupando attualmente:
> $ journalctl --disk-usage

> (...)

E io che per monitorare lo spazio occupato da codesti log mi
attardavo ancora su du -h /var/log/journal/ :/
Da notare che du dà la stessa risposta, sia che si sia utente, sia
che si sia root, mentre journalctl --disk-usage avverte l'utente che
non sta vedendo, in quanto tale, i messaggi degli altri utenti né
quelli del sistema. Risultato nel mio caso:

$ journalctl --disk-usage -q
Archived and active journals take up 864.1M in the file system.

$ du -h /var/log/journal/
2,0G /var/log/journal/

# du -m /var/log/journal/
1993 /var/log/journal/

# journalctl --disk-usage
Archived and active journals take up 1.9G in the file system.

Grazie mille Davide per condividere con noi la tua conoscenza e
delle informazioni che sono sempre importanti e interessanti.

peterpunk
--

,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/ printf("Mai un giorno senza una riga\n");

[pinguino]

On 31/10/21 17:36, Marco Bodrato wrote:
> Il 2021-10-31 16:42 pinguino ha scritto:
>> On 31/10/21 12:59, Alessandro Rubini wrote:
>>> Io faccio "du -x / | sort -n". Ovviamente da amministratore, perche`
>
> Intanto sottolineiamo che il suggerimento aveva una precisazione:
> **Ovviamente da amministratore**
>
>>> Utile anche, magari prima de "du", un "df -h" e "df -i" per vedere
>
>> df -h
>> File system     Dim. Usati Dispon. Uso% Montato su
>> /dev/sdb1        20G  5,3G     13G  30% /
>> /dev/sdb6        54G   40G     11G  79% /home
>> /dev/sda1        20G   20G       0 100% /mnt
>
> Quindi, quella piena è sda1, montata su /mnt, ed è piena nel senso
> dello spazio dati, non degli i-node.
>
>> Per questo ho dato un comando per scrivere nel file testo, perché nel
>> terminale non si leggeva tutto.
>> du -x / | sort -n > dux.txt
>
> Ma qui hai guardato lo spazio occupato nella partizione / ovverosia
> nella partizione /dev/sdb1

Con il comando (du -x / | sort -n > dux.txt), risulta la partizione più
grande. Cioè 5513780 / , 5,5 Giga, se non sbaglio.

>
>> Allego solo gli ultimi, che sono i più grandi
>
> ... :-) che è lo scopo di aver inserito "sort -n" nel suggerimento :-D
>
> Ti suggerisco, a questo punto, di vedere cosa succede con
>
> du -hx /mnt/ | sort -h

1,0G /mnt/usr/lib/x86_64-linux-gnu
1,4G /mnt/usr/share
2,7G /mnt/usr/lib
4,7G /mnt/usr
15G /mnt/root
15G /mnt/root/.cache
20G /mnt/

Metto solo quelli più grandi di 1 Giga. Ma allora nella cache di Root ci
sono 15 Giga ? Forse è li il problema. Ma come si fa a eliminare qualche
file senza danneggiare il sistema ?
Questo è il contenuto.
ls -ha /mnt/root/.cache
.
..
doc
gvfs
keyring-2TYMB1
mesa_shader_cache
tmptniz_t2tmTBjDhzgCRw2JS3xYQmV05uW.yUjHeq0qhisCjkWEDYmDc9Oop9BHnselS.HCC.PSs58V5W0U3fQ--rBNU.SSSjQLE-xx09G8FVdz465Dhicyx.jy_qWE9xRVPSeq5xsu8WpVa7mIi6P156inj5OBKw_2m2DLY2TO1xa9W7h60yLFqK0Kz3l8kDpv

L'ultimo file che inizia con tmptniz......................, sembra che
sia grande 15 Giga. Allora è questo il problema. Ma si può cancellare
senza avere problemi nel sistema ?

Se provo a cancellarlo mi dice che non esiste.
rm: impossibile rimuovere
'tmptniz_t2tmTBjDhzgCRw2JS3xYQmV05uW.yUjHeq0qhisCjkWEDYmDc9Oop9BHnselS.HCC.PSs58V5W0U3fQ--rBNU.SSSjQLE-xx09G8FVdz465Dhicyx.jy_qWE9xRVPSeq5xsu8WpVa7mIi6P156inj5OBKw_2m2DLY2TO1xa9W7h60yLFqK0Kz3l8kDpv':
File o directory non esistente

Grazie
Claudio

>
> Meglio come amministratore, per evitare che cartelle di utenti inattesi
> possano rimanere fuori dal conto.
>
>> 197424    /usr/lib/chromium
>> 200144    /usr/lib/firefox-esr
>> 279376    /opt/google/chrome
>
>> Se alcuni di quelli non sono utili o indispensabili al funzionamento del
>> sistema si possono cancellare ?
>
> C'è chromium, c'è firefox... il software non libero chrome di certo non è
> indispensabile :-P
>
> Ĝis,
> m

--
https://www.linkedin.com/in/claudio-sandrone

[Alessandro Rubini]

> L'ultimo file che inizia con tmptniz......................, sembra che
> sia grande 15 Giga.

E, quasi sicuramente, lo scaricamento si e` interrotto per fine dello
spazio libero.

> Allora è questo il problema. Ma si può cancellare
> senza avere problemi nel sistema ?

Sicuramente. Inizia con "tmp" e abita in .cache: non puo` essere imporante.
Giusto per curiosita`, guarderei col comando "file" di cose si tratta.

> Se provo a cancellarlo mi dice che non esiste.

> File o directory non esistente

E` un problema di caratteri speciali e/o strani nel nome. Quanto
divgitato (copiato col mouse) non corrisponde al nome.

Piu` che far completare a bash stessa usando <Tab> (che probabilmente
funziona), io preferisco

rm -i /mnt/tmp*

Cosi` il comando "rm" mi chiede conferma di ogni file, e posso verificare
che il mio asterisco mi abbia scelto solo quello che intendevo. In questo
caso sara` solo lui, ma una conferma e` comunque utile.

Se anche cosi` non trova niente, c'e` qualcosa di strano prima di
tmp, allora

rm -i /mnt/*tmp*

sicuramente funziona.

saluti
/alessandro, uso a file sbagliato con nomi strani

[pinguino]

On 31/10/21 23:55, peterpunk wrote:
> On Sat, 30 Oct 2021 10:48:12 +0200 Davide wrote:
>
>> mi sono accorto che non ho tantissimo spazio libero su /
>> e indagando ho scoperto che il journal di systemd stava occupando
>> diversi giga. Ho scoperto che al massimo, come impostazioni di
>> default, dovrebbe occupare 4 GByte.
>>
>> Per vedere quanto spazio sta occupando attualmente:
>> $ journalctl --disk-usage
>> (...)

Buongiorno Lista e Buona Festa a Tutti,

>
> E io che per monitorare lo spazio occupato da codesti log mi
> attardavo ancora su du -h /var/log/journal/ :/

> Da notare che du d� la stessa risposta, sia che si sia utente, sia

> che si sia root, mentre journalctl --disk-usage avverte l'utente che

> non sta vedendo, in quanto tale, i messaggi degli altri utenti n�

> quelli del sistema. Risultato nel mio caso:
>
> $ journalctl --disk-usage -q
> Archived and active journals take up 864.1M in the file system.

A me questo occupa poco spazio è normale ?
Archived and active journals take up 56.0M in the file system.

>
> $ du -h /var/log/journal/
> 2,0G /var/log/journal/

Questi sono così :
297M /var/log/journal/8ae34ea16cba45e9af8e9b5cef3cddb7
297M /var/log/journal/

>
> # du -m /var/log/journal/
> 1993 /var/log/journal/

Questi come sopra:
297 /var/log/journal/8ae34ea16cba45e9af8e9b5cef3cddb7
297 /var/log/journal/

>
> # journalctl --disk-usage
> Archived and active journals take up 1.9G in the file system.

Questo anche occupa poco spazio è normale ?
Archived and active journals take up 296.0M in the file system.

>
> Grazie mille Davide per condividere con noi la tua conoscenza e
> delle informazioni che sono sempre importanti e interessanti.
>
> peterpunk
>

Grazie
Claudio

--
https://www.linkedin.com/in/claudio-sandrone

[pinguino]

On 01/11/21 13:11, Alessandro Rubini wrote:
>> L'ultimo file che inizia con tmptniz......................, sembra che
>> sia grande 15 Giga.
>
> E, quasi sicuramente, lo scaricamento si e` interrotto per fine dello
> spazio libero.
>

Buongiorno Lista e Buona Festa a Tutti,

Questo problema mi era già capitato altre due volte. Ma avevo "risolto"
facendo la formattazione ed il restore di tutto, senza sapere ed
indagare sul perché.

>> Allora è questo il problema. Ma si può cancellare
>> senza avere problemi nel sistema ?
>
> Sicuramente. Inizia con "tmp" e abita in .cache: non puo` essere imporante.
> Giusto per curiosita`, guarderei col comando "file" di cose si tratta.

Purtroppo ho risolto "cancellando" il file con il file manager in forma
grafica. Cioè ho rinominato (con il tasto destro) a Pippo e poi ho
mandato nel cestino. Ha funzionato e per ora ho riavviato il disco A.
Quindi non posso dare il comando file. Forse può essere una sorta di
virus ? Comunque quando uso bleachbit, alla fine del controllo mi da
errore di spazio disco pieno, anche se lo spazio c'è ancora, sia sul
disco A che sul disco B.

>
>> Se provo a cancellarlo mi dice che non esiste.
>> File o directory non esistente
>
> E` un problema di caratteri speciali e/o strani nel nome. Quanto
> divgitato (copiato col mouse) non corrisponde al nome.
>
> Piu` che far completare a bash stessa usando <Tab> (che probabilmente
> funziona), io preferisco
>
> rm -i /mnt/tmp*
>
> Cosi` il comando "rm" mi chiede conferma di ogni file, e posso verificare
> che il mio asterisco mi abbia scelto solo quello che intendevo. In questo
> caso sara` solo lui, ma una conferma e` comunque utile.
>
> Se anche cosi` non trova niente, c'e` qualcosa di strano prima di
> tmp, allora
>
> rm -i /mnt/*tmp*
>
> sicuramente funziona.

Questo non li posso provare, perché dopo avere provato un paio di volte
con il comando semplice "rm Pippo" , ho provato con il file manager
grafico di mate. Con il tasto destro ho fatto rinomina e sposta nel
cestino. Mi ha detto che era troppo grande per il cestino e lo ha
eliminato.
Per una volta sembra che la grafica ha funzionato meglio del terminale.

Grazie
Claudio

>
> saluti
> /alessandro, uso a file sbagliato con nomi strani
>

--
https://www.linkedin.com/in/claudio-sandrone

[peterpunk]

On Mon, 1 Nov 2021 17:15:53 +0100 pinguino wrote:

>> (...)

>> $ journalctl --disk-usage -q
>> Archived and active journals take up 864.1M in the file system.
>
> A me questo occupa poco spazio è normale ?

Io non mi preoccuperei affatto ;)