[Résolu] Disque système saturé

Tabou · Le 26/12/2022, à 14:22

Bonjour Forum,

J'ai eu une notification d'espace libre saturé sur un disque (SDD) de 60 Go que j'ai échangé pour un disque de 120 Go. Le système m'indique dès le lendemain que ce disque est également saturé. J'ai pu déterminer, d'après les recherches que j'ai effectués, qu'il s'agissait de "system.log" qui enflait jusqu'à remplir mon disque (94 Go !) à nouveau. J'ai reporté cette commande (trouvée sur des forum) :

sudo journalctl --vacuum-size=100M

.. qui n'a pas résolu mon problème.
Je tourne un peu en rond, merci de votre aide.

Dernière modification par Tabou (Le 27/12/2022, à 12:17)

Vobul · Le 26/12/2022, à 14:35

Bah, t'emmerdes pas, sudo rm /var/log/system.log et hop, on repart sur de bonnes bases ! Si le fichier n'existe pas il est créé. Mais regarde dedans un peu quand même avant pour voir pourquoi il est si plein ! Sûrement un truc qui se répète.

Tabou · Le 26/12/2022, à 14:43

Merci Vobul, pour la commande ; cela ne va pas gonfler ma corbeille ? N'y a t-il pas une possibilité d'enrayer cette fixette du système ?
Bien à toi.

Tabou · Le 26/12/2022, à 14:46

Je suis allé voir dans syslog, et voilà ce que j'y trouve, en dizaine de milliers d'exemplaires :

12-26 13:48 tracker-extract:  gst_buffer_get_sizes_range: assertion 'GST_IS_BUFFER (buffer)' failed
12-26 13:48 tracker-extract:  gst_queue_array_peek_nth: assertion 'idx < array->length' failed

!!

Vobul · Le 26/12/2022, à 15:59

Non, la commande "rm" ne passe pas par la corbeille. Ça supprime direct.

Il semble que cela provienne de tracker-extract, un truc qui indexe tes fichiers (et semble être un bon gros consommateur de ressources ! https://www.debian-fr.org/t/en-finir-av … act/84378).

Teste "tracker reset --hard", source : https://askubuntu.com/questions/1258348 … ith-errors

geole · Le 26/12/2022, à 16:46

Bonjour.
Fais ce qui est décrit au paragraphe 4.6 de cette documentation.

iznobe · Le 26/12/2022, à 18:38

Bonjour , @Vobul : dans ton lien on peut voir 2 commentaires supplémentaires a la recherche du soucis du demandeur :

tracker reset --hard
appears to have fixed the problem. I will try a restart and make an update –
WhisperingShiba
Jul 12, 2020 at 0:16
This fix did not persist through a restart. I am still looking for any insight people may have. –
WhisperingShiba
Jul 12, 2020 at 17:45

le dernier , si je comprends bien , semble dire , que le probleme n ' est pas resolu , et qu ' apres un reboot il faut repasser systematiquement la même commande pour avoir un truc presque stable .

@geole , ta solution ne solutionnera pas le probleme non plus , puisque ca ecrit en permanence dans les logs , ou bien je n ' ai pas vu exactement quelle partie pourrait solutionner le soucis .

bon , j ' avoue que ce n' est pas ce que l' on peut faire de mieux , mais on peut desactiver tracker-miner de façon certaine avec ces commandes :

sudo chmod -x /usr/libexec/tracker-miner-fs-3
sudo chmod -x /usr/libexec/tracker-extract-3

ca permet de gagner en ressources et plus de journal qui gonflera .

Dernière modification par iznobe (Le 26/12/2022, à 18:46)

Tabou · Le 27/12/2022, à 12:16

Bonjour iznobe, merci pour ces précieux conseils. J'ai appliqué tes préconisations et ai obtenu ce résultat :

tabou@tabou:~$ sudo chmod -x /usr/libexec/tracker-miner-fs-3
[sudo] Mot de passe de tabou : 
chmod: impossible d'accéder à '/usr/libexec/tracker-miner-fs-3': Aucun fichier ou dossier de ce type
tabou@tabou:~$ sudo chmod -x /usr/libexec/tracker-extract-3
chmod: impossible d'accéder à '/usr/libexec/tracker-extract-3': Aucun fichier ou dossier de ce type

J'ai aussi appliqué la solution proposée par geole, qui n'a pas causé de problème.
Aujourd'hui, le disque SSD de 120 Go que j'ai installé est utilisé à 19%, à suivre...
Je mets ce problème comme résolu, quitte à le déterrer.
Merci Vobul, geole et iznobe pour votre aide précieuse et amicale,
Bonne fêtes à vous...

geole · Le 27/12/2022, à 15:18

iznobe a écrit :

@geole , ta solution ne solutionnera pas le problème non plus , puisque ça écrit en permanence dans les logs , ou bien je n ' ai pas vu exactement quelle partie pourrait solutionner le soucis .
.

Bonjour
Je n'ai pas dit que ma solution réglait le problème mais seulement le problème des log qui prennent beaucoup de place. La raison: On déactive froidement leur écriture pour ne conserver que l'écriture dans le journal. Cela est bien suffisant pour trouver ultérieurement la cause d'un ordinateur qui rame.

Le journal est conçu pour ne jamais dépasser 4Go. Il comprend la commande vacuum contrairement à la vieille génération de syslog et kern.log

Dernière modification par geole (Le 27/12/2022, à 15:20)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/12/2022, à 14:22

[Résolu] Disque système saturé

#2 Le 26/12/2022, à 14:35

Re : [Résolu] Disque système saturé

#3 Le 26/12/2022, à 14:43

Re : [Résolu] Disque système saturé

#4 Le 26/12/2022, à 14:46

Re : [Résolu] Disque système saturé

#5 Le 26/12/2022, à 15:59

Re : [Résolu] Disque système saturé

#6 Le 26/12/2022, à 16:46

Re : [Résolu] Disque système saturé

#7 Le 26/12/2022, à 18:38

Re : [Résolu] Disque système saturé

#8 Le 27/12/2022, à 12:16

Re : [Résolu] Disque système saturé

#9 Le 27/12/2022, à 15:18

Re : [Résolu] Disque système saturé

Pied de page des forums