Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

Pages : 1 2

#1 Le 21/10/2018, à 21:08

Nuliel

/var/log/journal très lourd?

Bonsoir,

Je viens de remarquer que mon /var/log/journal pèse 650 Mo, ce qui est assez lourd pour des journaux systemd je trouve. Comment faire pour trouver les infos redondantes, et faire une rotation des journaux afin de les vider?
Pouvez vous donner le poids du votre:

du -ch /var/log/journal/

Edit: j'ai pas assez cherché, j'ai trouvé deux commandes:

journalctl --disk-usage

pour avoir le poids du journal

journalctl --vacuum-size=200M

pour vider les logs proprement

Reedit:
j'ai un petit tas de

oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:devices: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:..: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:virtual: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:devices: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:dmi: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:virtual: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:id: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:dmi: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:sys: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:id: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:bus: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:pci: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:drivers: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:sys: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:bus: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:sys: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:pci: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:bus: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:pci: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:sys: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:drivers: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:class: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:dmi: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:sys: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:id: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:bus: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:..: Chemin relatif ignoré
oct. 21 15:19:58 naziel-HP-desktop ureadahead[259]: ureadahead:sys: Chemin relatif ignoré

70952 lignes contenant ureadahead

Dernière modification par Nuliel (Le 21/10/2018, à 21:20)

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#2 Le 21/10/2018, à 21:23

jpoc

Re : /var/log/journal très lourd?

bonjour
https://doc.ubuntu-fr.org/logrotate

Hors ligne

#3 Le 21/10/2018, à 21:32

domi301

Re : /var/log/journal très lourd?

salut

après un upgrade vers 18.10 (hier) j'ai 

 du -ch /var/log/journal/
1,4G	/var/log/journal/a5cae954e0224cc09c4832bd16b45b3f
1,4G	/var/log/journal/
1,4G	total
$ journalctl --disk-usage
Archived and active journals take up 1.3G in the file system.

quand je regarde en détails j'ai pas mal d'archives .gz qui datent de 2017 sous /var/log ...

mais pas de trace de "unread" chez moi

[edit] bon au final c'est normal pour les nombreux fichiers gz
il y a des parametres par defaut correspondant à 12 mois dans /etc/logrotate.d/  exemple 

$ more alt*
/var/log/alternatives.log {
	monthly
	rotate 12
	compress
....

Dernière modification par domi301 (Le 21/10/2018, à 21:50)

Lubuntu / Xubuntu ==> redonner vie à des machines abandonnées
en cas de besoin => http://forum.ubuntu-fr.org/viewtopic.php?id=1069631

Hors ligne

#4 Le 21/10/2018, à 21:36

Nuliel

Re : /var/log/journal très lourd?

Bon finalement avec mes 650 Mo, c'est pas si lourd (mais c'est lourd quand même je trouve)
C'est pas unrrad mais ureadahead, ce qui permet d'avoir un démarrage plus rapide de l'ordi
Tu peux donner le retour de

 journalctl | grep ureadahead | wc -l

Dernière modification par Nuliel (Le 21/10/2018, à 21:48)

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#5 Le 21/10/2018, à 21:56

domi301

Re : /var/log/journal très lourd?

pas mieux ;-) 

 $  journalctl | grep ureadahead | wc -l
0

d'accord pour le poids sur le principe
je ne suis pas convaincu du besoin de logs de 12 mois dans les paramètres par défaut...
mais pas de soucis de débordement pour ma partition.
tous mes dossiers lourds (documents... sont déportés sur une autre partition

Lubuntu / Xubuntu ==> redonner vie à des machines abandonnées
en cas de besoin => http://forum.ubuntu-fr.org/viewtopic.php?id=1069631

Hors ligne

#6 Le 21/10/2018, à 22:01

Nuliel

Re : /var/log/journal très lourd?

Ok, j'ai trouvé https://askubuntu.com/questions/749224/ … elative-pa , mais je suis sur une clean install de la 18.04....
J'ai mis la commande pour vider mais bon, j'aimerais bien ne pas remplir pour rien

C'est encore d'actualité https://bugs.launchpad.net/ubuntu/+sour … ug/1579580

Dernière modification par Nuliel (Le 21/10/2018, à 22:10)

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#7 Le 22/10/2018, à 05:55

NicoApi73

Re : /var/log/journal très lourd?

Salut Naziel,

Pour logrotate : 

sudo logrotate --force /etc/logrotate.conf

Les archives sont à vider avec 

echo | sudo tee nom_de_l_archive

Je verrai plus tard si j'arrive à trouver des infos.

L'ensemble du /var/log (sur une 16.04), c'est 510Mo chez moi.

Hors ligne

#8 Le 22/10/2018, à 06:12

NicoApi73

Re : /var/log/journal très lourd?

Voici ce que j'ai trouvé : https://www.dedoimedo.com/computers/ubu … -boot.html
Regarde à Post-boot activity :

There are two solutions to the issue - disable the ureadahead service, which might impact boot times, or quieten its output. In both cases, you need to make changes to the Systemd configuration. First, you can disable the service:

sudo systemctl disable ureadahead.service
Removed /etc/systemd/system/default.target.wants/ureadahead.service.

Alternatively, edit the ureadahead configuration file /etc/systemd/system/ureadahead.service.d/quiet.conf and add the following lines:

[Service]
ExecStart=
ExecStart=/sbin/ureadahead -q

Hors ligne

#9 Le 22/10/2018, à 07:15

moko138

Re : /var/log/journal très lourd?

Voir les messages #8 et 11 de grandtoubab en ./viewtopic.php?pid=21739345#p21739345.


Désactiver ureadahead est une vieille lune et une fausse bonne idée ; le concepteur de ce logiciel l'avait brillamment démontré il y a une demi-douzaine d'années.
J'ignore si ureadahead est aussi utile qu'avant, quand le système est sur ssd. Mais ce qui est à comprendre c'est :
comment 700.000 70.000 lignes répétitives ont pu être journalisées.


Accessoirement, je rappelle à tous :
  - que laisser /var/log sur le ssd est un choix qui nuit à sa longévité ;
  - que le poids dévolu à /var/log peut aisément être plafonné dans le fstab ;
  - que si le poids de /var/log dépasse quelques dizaines de Mo, il y a un problème à identifier et éliminer dans les meilleurs délais.

Dernière modification par moko138 (Le 22/10/2018, à 14:49)

%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#10 Le 22/10/2018, à 08:23

Nuliel

Re : /var/log/journal très lourd?

J'ai mis un lien vers le bug en question je pense: https://bugs.launchpad.net/ubuntu/+sour … ug/1579580 . Il est proposé d'essayer la 18.10, signe que le bug est encore d'actualité.
C'est 70 000, pas 700 000 smile

moko138 a écrit :

- que si le poids de /var/log dépasse quelques dizaines de Mo, il y a un problème à identifier et éliminer dans les meilleurs délais.

C'est pour cela que j'ai ouvert ce fil smile

Je vais voir si je continue à être spammé par ces messages (j'ai vidé les logs)

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#11 Le 22/10/2018, à 08:53

rj45

Re : /var/log/journal très lourd?

bonjour naziel
( 

journalctl --vacuum-size=200M

)

pour la même commande que toi ici donne 

Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-0000000000000001-000572732714f637.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-29999@a5242c8bb78b4d1b8ac301141c34c81c-000000000000033e-00057273275073aa.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-0000000000001721-0005728676b0d543.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-29999@a5242c8bb78b4d1b8ac301141c34c81c-000000000000172b-0005728676e00573.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-0000000000002023-0005734ce2093c9c.journal (72.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-0000000000005b12-00057375d9865fb9.journal (40.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-0000000000021044-000573b278ffd553.journal (24.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-0000000000021046-000573b2790d2238.journal (24.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000002ba51-000573d71531c4b3.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000002ba55-000573d71549cf5f.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000002dac6-000573d841d3da3c.journal (32.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000002daca-000573d841e95eab.journal (24.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000003b132-000573ebfc941f17.journal (32.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000003b136-000573ebfca21041.journal (24.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000498b4-00057415584da9b6.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000498b6-00057415585b837a.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000004b4ea-0005741ae40abe7a.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000004b4eb-0005741ae40e6cc3.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000004d706-0005741b508cb18f.journal (24.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000004d70e-0005741b509beb71.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-0000000000055aad-0005742dbcbccda9.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-0000000000055aaf-0005742dbcc57839.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-0000000000056efe-0005742e1ce57b0f.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-0000000000056f04-0005742e1d16e7fb.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-0000000000058626-0005742f72a9ee57.journal (40.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-0000000000058628-0005742f72c306ba.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000665de-0005743d02787168.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000665e2-0005743d028aadb9.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000006ac77-000574654125622c.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000006ac78-00057465412b79da.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000006bd79-00057478e7497b67.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000006bd7f-00057478e770007d.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000006e7ef-000574a26e1ccc49.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000006e7f3-000574a26e29a7cf.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000701ad-000574f24d45cb0f.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000701b2-000574f24d5b3055.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000732f8-000575342c1c5269.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000732fb-000575342c211601.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000754ec-0005758499760014.journal (32.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000754f2-00057584998c6d90.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000007df45-000575bfbcbfa6f0.journal (16.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-000000000007df4d-000575bfbcdb32b0.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-000000000008104f-000575ceb832381c.journal (120.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-0000000000081051-000575ceb8389847.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000a816a-000575e18a2254b4.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000a8175-000575e18a5f7861.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000a9570-000575ec6b77913e.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000a9575-000575ec6b87eee6.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000ab3f4-000575fc3bcd4be4.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000ab3f8-000575fc3bd501db.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000ac05b-000575ff46a01b81.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000ac05e-000575ff46a84f1c.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000acc04-0005760b9f07634e.journal (88.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000acc07-0005760b9f20c1e0.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000c641b-0005761f456c86e8.journal (48.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/user-1000@e8871a785038439598fd78ecb8571c19-00000000000c6421-0005761f458c82ed.journal (8.0M).
Deleted archived journal /var/log/journal/db18f3bee0e8411496f2aef306c69c06/system@8a7f63dc17cc475abf4d2d591c048907-00000000000d43f3-000576c5ccd00844.journal (8.0M).
Vacuuming done, freed 1.0G of archived journals from /var/log/journal/db18f3bee0e8411496f2aef306c69c06.

Hors ligne

#12 Le 22/10/2018, à 09:40

Nuliel

Re : /var/log/journal très lourd?

@rj45: tu as avec cette commande fait du nettoyage dans les journaux systemd, tu as supprimé 1 Go d'archives, et il te reste encore 200Mo de journaux encore en théorie.

Ce serait intéressant de faire une commande pour trouver ce qui spamme pour chacun (et une commande pour faire des nettoyages plus réguliers ou limiter les logs)

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#13 Le 22/10/2018, à 09:46

maxire

Re : /var/log/journal très lourd?

Salut,

Le journal ou plutôt les journaux sont maintenant gérés par SystemD pour la plupart.
La gestion de la taille maximale du journal est définie dans le fichier de configuration /etc/systemd/journald.conf en sachant que par défaut cette taille est de 4GO ou 10% à 15% de la taille du système de fichiers hébergeur.
Lire la page man de journald.conf pour plus d'information.
Un moyen radical de ne plus être ennuyé est de supprimer le répertoire /var/log/journal, dans ce cas le journall est généré en mémoire temporaire et perdu lors de l'arrêt système.

Maxire
Archlinux/Mate + Ubuntu 22.04 + Archlinux/Gnome sur poste de travail

Hors ligne

#14 Le 22/10/2018, à 09:56

Nuliel

Re : /var/log/journal très lourd?

naziel@naziel-HP-desktop:~$ cat /etc/systemd/journald.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See journald.conf(5) for details.

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K

(tout est par défaut)
Et le man de journald.conf indique

The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G.

Donc on se retrouve par défaut avec au max 4 Go de journaux.

Le plus simple je pense est de mettre SystemMaxUse=200M pour toujours avoir les 200 M de derniers journaux

Dernière modification par Nuliel (Le 22/10/2018, à 09:57)

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#15 Le 22/10/2018, à 10:13

rj45

Re : /var/log/journal très lourd?

a voire aussi le spice-vdagent

Hors ligne

#16 Le 22/10/2018, à 10:52

grandtoubab

Re : /var/log/journal très lourd?

Salut
Voici comment j'ai réduit le bavardage et l'encombrement du journal

https://bidouilledebian.wordpress.com/2 … s-systeme/

NB dans Debian le paquet readahead n'existe plus et systemd la viré aussi

https://cgit.freedesktop.org/systemd/systemd/tree/NEWS#n76 a écrit :

https://cgit.freedesktop.org/systemd/sy … e/NEWS#n76
systemd's readahead implementation has been removed. In many
          circumstances it didn't give expected benefits even for
          rotational disk drives and was becoming less relevant in the
          age of SSDs. As none of the developers has been using
          rotating media anymore, and nobody stepped up to actively
          maintain this component of systemd it has now been removed.

Dernière modification par grandtoubab (Le 22/10/2018, à 11:09)

Linux tout seul sur HP Pavilion DV7 et Acer Aspire T650, Canon MG3650 en wifi
Debian 11 Bullseye Gnome/Xorg, Gnome/Wayland avec SDDM
https://bidouilledebian.wordpress.com/
ON M'A VU DANS LE VERCORS, SAUTER A L'ELASTIQUE..... J'AI DANS LES BOTTES DES MONTAGNES DE QUESTIONS....

Hors ligne

#17 Le 22/10/2018, à 12:38

diesel

Re : /var/log/journal très lourd?

Bizarre.

Chez moi, avec ma 18.04 installée depuis quelques mois (j'ai attendu un peu), le répertoire journal ne fait qu'un peu moins de 2MO. Et je n'ai rien configuré de spécial.

[EDIT] Oups !, je viens de vérifier. Je me suis trompé d'unité : 1,9GO !

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 22/10/2018, à 12:40)

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

#18 Le 22/10/2018, à 13:25

Nuliel

Re : /var/log/journal très lourd?

Finalement, je suis pas le seul à avoir des journaux en quantité industrielle!
@grandtoubab: je préfère garder l'entièreté des logs les plus récents plutôt que les erreurs les plus graves, ureadahead apparaît 70 000 fois mais c'est pas une erreur, et je suis bien content de savoir que c'est ce programme qui me pourrit en parti les logs
Par curiosité diesel83140 , que donne

 journalctl | grep ureadahead | wc -l

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#19 Le 22/10/2018, à 14:42

NicoApi73

Re : /var/log/journal très lourd?

Tu peux éviter les ureadahead : cf post #8

Hors ligne

#20 Le 22/10/2018, à 14:58

rj45

Re : /var/log/journal très lourd?

NicoApi73 a écrit :

Tu peux éviter les ureadahead : cf post #8

tu peu expliquer pourquoi ? merci !?

Hors ligne

#21 Le 22/10/2018, à 17:10

Nuliel

Re : /var/log/journal très lourd?

@rj45: La commande proposée par Nico permet de stopper le service ureadahead à chaque démarrage, donc fatalement il ne polluera plus les logs.

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#22 Le 22/10/2018, à 17:38

erresse

Re : /var/log/journal très lourd?

Pour un log de 105Mo, j'ai 12439 lignes de ureadahead (Chemin relatif ignoré)...
Variante Ubuntu-Mate 18.04.1 depuis juillet.

Plus de 50 ans d'informatique, ça en fait des lignes de commandes en console, mais on n'avait pas le choix...
Excellente raison pour, aujourd'hui qu'on le peut, utiliser au maximum les INTERFACES GRAPHIQUES !
Important : Une fois le problème solutionné, pensez à clore votre sujet en ajoutant [Résolu] devant le titre du 1er message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci.

Hors ligne

#23 Le 22/10/2018, à 17:51

inbox

Re : /var/log/journal très lourd?

Salut,

La 2ème partie du #8 est à privilégier, vu que cela laisse ureadahead en fonctionnement et se contente de le rendre muet (quiet) avec "-q".

A+

[Edit]À noter que l'upgrade vers 18.10 supprime le paquet ureadahead.

Dernière modification par inbox (Le 22/10/2018, à 17:53)

Un problème résolu ? Indiquez le en modifiant le titre du sujet.

En ligne

#24 Le 23/10/2018, à 08:06

NicoApi73

Re : /var/log/journal très lourd?

moko138 a écrit :

  - que laisser /var/log sur le ssd est un choix qui nuit à sa longévité ;

Bonjour,

Que proposes-tu pour mettre /var/log en dehors du ssd? un bind dans fstab?

Hors ligne

#25 Le 23/10/2018, à 10:14

moko138

Re : /var/log/journal très lourd?

NicoApi73 a écrit :
moko138 a écrit :

  - que laisser /var/log sur le ssd est un choix qui nuit à sa longévité ;

Que proposes-tu pour mettre /var/log en dehors du ssd? un bind dans fstab?

Par exemple. Mais un bind vers quoi ?
Le bind n'est pas nécessaire.


Certains mettent plutôt une ligne montant /var/log/ dans leur partition de données sur HDD :

UUID=(...)   /Data_456    ext4    defaults,nofail   0  2
/var/log/    /Data_456/var/log    option-limitant-le-POIDS-de-/var/log/
#

AJOUT 1, de mai 2020 :
man mount dit :

Options de montage pour ext4
       max_dir_size_kb=n
Cela limite la taille des répertoires de  tel[le]  sorte  que  les  tentatives  de  les
étendre  au-delà  de la limite indiquée en kilooctet déclenchera une erreur ENOSPC.

D'où, pour (par exemple) 100 Mio = 104857,6 ko :

/var/log/    /Data_456/var/log     max_dir_size_kb=104857
#

/!\  Ne pas oublier de passer à la ligne !
                                       FIN d'ajout


Mais je crois que si j'avais un SSD et un HDD, je procèderais comme ceci, avec une petite (200 Mio)  partition dédiée sur HDD :

# VARLOG-XUB1804 est sur <uuid> à la date du...
LABEL=VARLOG-XUB1804   /var/log/      ext4    defaults,nofail   0  2
#

Ça me paraît beaucoup plus simple, et de loin.
Et plus sain, parce que les données restent séparées du système. Et qu'une éventuelle récupération de données s'en trouve abrégée et simplifiée.

= =


Ou encore je m'amuserais à tester deux tâches cron inspirées de Daniel López Azaña, en http://www.daniloaz.com/en/how-to-preve … huge-size/
Si on admet de purger partiellement, syslog et kern.log, alors on doit pouvoir transposer les solutions conçues pour .xsession-errors, par Daniel López Azaña.
Elles consistent à limiter le fichier en poids et en nombre de lignes, avec sauvegarde des dernières lignes.
  Mais là, ce serait plutôt un jeu.  smile

= =


AJOUT 2, de mai 2020 :
À ce jour, aucune de ces manip' ne dispensent du paramétrage indiqué au message #40.

Dernière modification par moko138 (Le 04/05/2020, à 05:45)

%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

Pages : 1 2