Swisslinux.org

François Marthaler · 11 Mar 2022 16:23:26

Bonjour,

Hier, alors que je tentais de mettre à profit le temps de mon trajet TGV aller-retour à Paris (très mauvaise connexion Internet; 3 minutes pour envoyer un courriel de 3 lignes!?!), mon courrielleur Thunderbird m'a signalé que le SSD ne disposait pas de suffisamment de place pour compacter les messages (entrants ou sortants, je ne sais plus).

Selon l'utilitaire Analyseur d'utilisation des disques, mon SSD Samsung 970 EVO Plus de 500 GB n'est occupé qu'à 258.9 GB:

Mais il n'a pas accès au répertoire /etc/cups/ssl.

Dans Moniteur système, onglet Moniteur de fichiers, le système m'indique que ce SSD contient 446.9 GB et qu'il est plein à 95%:

Voilà qui me rappelle le cas récent de ce SSD saturé de messages d'erreurs de plus de 100 GB (!) en provenance d'un pilote pour une imprimante Canon: https://swisslinux.org/forum/viewtopic.php?id=6373. Comme indiqué au post #5 de cette discussion, j'ai tenté de voir de que renvoyait la commande suivante:

Code:

francois@francois-N240JU:~$ sudo du -sch /var/tmp/*
[sudo] Mot de passe de francois : 
4.0K    /var/tmp/audacity-francois
4.0K    /var/tmp/AUTOFIRMA_CONFIGURATOR.afirma.log.xml
4.0K    /var/tmp/ParametrizadorConfiguradorFnmt.fnmt.log.xml.0
8.0K    /var/tmp/systemd-private-94d1dfb29a7b4acd9aed99ddc571ad3e-colord.service-Pzel7g
8.0K    /var/tmp/systemd-private-94d1dfb29a7b4acd9aed99ddc571ad3e-ModemManager.service-A8Fp0e
8.0K    /var/tmp/systemd-private-94d1dfb29a7b4acd9aed99ddc571ad3e-switcheroo-control.service-ZXu7tj
8.0K    /var/tmp/systemd-private-94d1dfb29a7b4acd9aed99ddc571ad3e-systemd-logind.service-shooqf
8.0K    /var/tmp/systemd-private-94d1dfb29a7b4acd9aed99ddc571ad3e-systemd-resolved.service-sYjl3i
8.0K    /var/tmp/systemd-private-94d1dfb29a7b4acd9aed99ddc571ad3e-systemd-timesyncd.service-SC76nh
8.0K    /var/tmp/systemd-private-94d1dfb29a7b4acd9aed99ddc571ad3e-upower.service-dGENSh
68K    total

Rien d'anormal dans les fichiers temporaires, donc.

François Marthaler · 11 Mar 2022 18:20:40

Par analogie, j'ai tenté d'en savoir plus sur le contenu du répertoire /etc/cups:

Code:

francois@francois-N240JU:~$ sudo du -sch /etc/cups/*
32K    /etc/cups/cups-browsed.conf
8.0K    /etc/cups/cupsd.conf
4.0K    /etc/cups/cups-files.conf
4.0K    /etc/cups/interfaces
76K    /etc/cups/ppd
4.0K    /etc/cups/printers.conf
4.0K    /etc/cups/printers.conf.O
4.0K    /etc/cups/raw.convs
4.0K    /etc/cups/raw.types
4.0K    /etc/cups/snmp.conf
4.0K    /etc/cups/ssl
4.0K    /etc/cups/subscriptions.conf
4.0K    /etc/cups/subscriptions.conf.O
156K    total

Là aussi, rien d'inquiétant...

François Marthaler · 11 Mar 2022 18:28:54

Ne sachant trop quoi faire, j'ai tenté de récupérer de la place sur mon SSD avec les commandes suivantes passées dans un terminal ([Ctrl]+[Alt]+[T]):

Code:

sudo apt update
sudo apt upgrade
sudo apt autoremove
sudo apt autoclean
sudu update-grub
reboot

Mais cela n'a rien changé et mon SSD de 500 GB est toujours occupé à 95%.

Toute idée sera la bienvenue!...

François Marthaler · 11 Mar 2022 18:34:16

En cherchant sur Internet "error opening directory '/etc/cups/ssl' permission denied", je suis tombé sur cette discussion sur askubuntu.com.

Il est précisé, If you really suspect that something is wrong in this directory in terms of disk usage, you can look into it by sudo ls -l /etc/cups/ssl.

Voilà ce que cela donne:

Code:

francois@francois-N240JU:~$ sudo ls -l /etc/cups/ssl
[sudo] Mot de passe de francois : 
total 0

De toute évidence, le problème est ailleurs!

J'espère que mon sauveur Eggman saura me dire comment trouver...

Pour l'heure, je n'ai pas trop de problème, car la sauvegarde automatique et quotidienne sur le serveur du bureau avec DéjàDup ne sauvegarde que les données se trouvant dams mon répertoire /home et pas les 250 GB parasites qui doivent se trouver ailleurs...

Eggman · 12 Mar 2022 07:48:58

Bonjour François.

Au vu des 2 images que tu as postées, je comprends que :
- ton dossier home semble rempli a hauteur de ~260Gio
- l’ensemble de la partition disque est occupée à hauteur de ~450Gio/490Gio

Ce qui signifie qu'il y a ~190Gio occupés ailleurs.

Comme on le voit sur la première image, un partie des dossier n'a pu être évaluée à cause des droits d'accès.

Il faudrait relancer baobab (Analyseur d'utilisation des disques, première image) en tant que root et analyser tout le disque depuis /.

Donc, au terminal, il faut lancer:

Code:

sudo baobab

Ensuite, comme d'hab, cliquer sur /

François Marthaler · 13 Mar 2022 17:19:26

Bonjour Eggman,

J'ai lancé l'analyseur d'utilisation des disques en tant que root et voici ce que je trouve à la racine:

186.7 GB dans /.local/share/Trash/files/output. J'hésite cependant à effacer tout ce qui se trouve dans Trash...

En me déplaçant dans l'arborescence, je trouve bien environ 200'000 fichiers .jpg dans le sous-répertoire ~/.local/share/Trash/files/output/jpg:

Code:

...
475660290.jpg  583644033.jpg  598126400.jpg  702924221.jpg  88794784.jpg
475660545.jpg  583644414.jpg  598126464.jpg  702924399.jpg  88974762.jpg
475662787.jpg  583644418.jpg  598127432.jpg  702924545.jpg  89707522.jpg
475663680.jpg  583644422.jpg  598128592.jpg  702924589.jpg  89707740.jpg
475663912.jpg  583644441.jpg  598128608.jpg  702924810.jpg
root@francois-N240JU:~/.local/share/Trash/files/output/jpg#

Mais je n'ai pas l'ombre d'une idée d'où ils viennent...

Eggman · 15 Mar 2022 19:37:02

Ces fichiers ne sortent pas de nulle part!

Il s0agit en fait, de la poubelle du root.
L'explication la plus vraisemblable est que le root a mis à la poubelle des fichiers via l'le navigateur de fichiers, sans vider la poubelle.

Il a suffit de faire un `sudo nautilus`ou équivalent pour avoir le navigateur de fichiers.

Pour voir le contenu de la poubelle, il suffit de relancer le navigateur de fichiers en tant que root, puis après avoir vérifié qu'il s'agit bien de fichiers à effacer, de vider la poubelle.

Cela dit, de façon générale, ce n'est pas une bonne idée de lancer le navigateur de fichiers en tant que root.

François Marthaler · 16 Mar 2022 10:14:03

Bonjour Eggman.

J'ai lancé le navigateur de fichiers en tant que root avec la commande:

Code:

sudo nautilus

J'ai cliqué sur la corbeille (qui s'affiche comme si elle était vide) et le système me répond: Désolé, impossible d'afficher tout le contenu de "trash:///": Opération non prise en charge.

Je suis ensuite allé dans /.local/share/Trash/files/output/jpg où se trouvent environ 200'000 fichiers jpg de toutes sortes, dont des logos d'entreprises, un scan de passeport, des captures d'écran reçues de clients, etc:

Merci pour l'aide...

Eggman · 16 Mar 2022 20:33:10

Je me demande si trash-cli n'est pas installé sur votre machine.
Ce logiciel remplace la commande rm et envoie à la poubelle les fichiers "effacés" via la commande rm.
Cela pourrait expliquer une telle quantité de fichiers dans la poubelle du root.

A. Si tel est le cas,

Code:

sudo trash-list

devrait lister le contenu de la poubelle du root et

Code:

sudo trash-empty

devrait la vider.

-----

Interlude illustratif chez moi:

Code:

root ~ 0 # ## Je suis root, dans /root. `pwd` affiche le dossier dans lequel je me trouve.
root ~ 0 # pwd
/root
root ~ 0 # ## Je créé des fichiers sans intérêts pour la démonstration,
root ~ 0 # touch toto tata titi
root ~ 0 # ## je les efface via rm. Dans les faits, je les mets à la poubelle
root ~ 0 # rm toto tata titi
root ~ 0 # ## j'affiche le contenu de la poubelle du root
root ~ 0 # trash-list 
2022-03-16 20:12:00 /root/titi
2022-03-16 20:12:00 /root/tata
2022-03-16 20:12:00 /root/toto
root ~ 0 # ## Maintenant, j'affiche l'ensemble des dossiers et fichiers dans /root/.local/share/Trash/
root ~ 0 # tree /root/.local/share/Trash/
./root/local/share/Trash/
├── files
│   ├── tata
│   ├── titi
│   └── toto
└── info
    ├── tata.trashinfo
    ├── titi.trashinfo
    └── toto.trashinfo

2 directories, 6 files
root ~ 0 # ## On voit bien les fichiers effacés et des fichiers .trashinfo
root ~ 0 # ## j'en affiche leur contenu
root ~ 0 # cat .local/share/Trash/info/*
[Trash Info]
Path=/root/tata
DeletionDate=2022-03-16T20:12:00
[Trash Info]
Path=/root/titi
DeletionDate=2022-03-16T20:12:00
[Trash Info]
Path=/root/toto
DeletionDate=2022-03-16T20:12:00
root ~ 0 # ## Ça indique le chemin d'origine et la date de l’effacement
root ~ 0 # ## je vide la poubelle
root ~ 0 # trash-empty 
root ~ 0 # ## j'en affiche le contenu
root ~ 0 # trash-list
root ~ 0 # ## il n'y a plus rien. Normal
root ~ 0 # ## Maintenant, j'affiche l'ensemble des dossiers et fichiers dans /root/.local/share/Trash/
root ~ 0 # tree .local/share/Trash/
.local/share/Trash/
├── files
└── info

2 directories, 0 files
## Plus rien. Tout est normal
root ~ 0 #

-----

B. Si tel n'est pas le cas et que les documents qui se trouvent dans la poubelle du root ne présentent aucun intérêt et peuvent être définitivement purgés, on peut effacer le contenu du dossier définitivement avec la commande suivante:

Code:

sudo rm -rf /root/.local/share/Trash/*

Attention cependant de bien vérifier le chemin, la commande rm ne pardonne rien en cas d'erreur.

François Marthaler · 17 Mar 2022 21:49:04

Bonsoir Eggman,

Visiblement, trash-cli n'est pas installé sur ma machine:

Code:

francois@francois-N240JU:~$ sudo trash-list
[sudo] Mot de passe de francois : 
sudo: trash-list : commande introuvable
francois@francois-N240JU:~$ trash-cli
trash-cli : commande introuvable
francois@francois-N240JU:~$ trash-cli
trash-cli : commande introuvable
francois@francois-N240JU:~$ trash-empty

La commande « trash-empty » n'a pas été trouvée, mais peut être installée avec :

sudo apt install trash-cli

Dans votre exemple très didactique (titi, tata, toto), je ne vois pas la suite de l'arborescence /files/output qui continue à m'intriguer...

Comme j'ai à nouveau des messages d'alerte de Thunderbird m'informant que l'espace disque est insuffisant pour compacter (et même pour enregistrer une simple capture d'écran pour le montrer!?!), je vais effacer tout ce qui se trouve dans la poubelle de root...

Après avoir vérifié deux fois le chemin d'accès, j'ai passé la commande proposée:

Code:

sudo rm -rf /root/.local/share/Trash/*

Avec la commande man rm (manuel d'utilisation de la commande rm), j'ai vérifié la signification des options -rf:

Code:

OPTIONS
       Remove (unlink) the FILE(s).

       -f, --force
              ignore nonexistent files and arguments, never prompt
...

       -r, -R, --recursive
              remove directories and their contents recursively
...

Cela fait, le répertoire /root/.local/share/Trash/files/output contient toujours 186.7 GB!?!

Et, après un reboot, la situation reste la même. Je désespère...

François Marthaler · 18 Mar 2022 12:18:42

J'ai soumis le cas à l'informaticien de La Bonne Combine, qui a ouvert un terminal sous root avec sudo su -, s'est déplacé dans le fameux répertoire /root/.local/share/Trash/files/output pour lister ce qu'il contenait:

Code:

root@francois-N240JU:~/.local/share/Trash/files/output# ls -l
total 124252
-rw-r--r-- 1 francois root 80183296 jan 12 02:05 audit.txt
drwxr-xr-- 2 francois root     4096 jan 12 01:45 avi
drwxr-xr-- 2 francois root    45056 jan 12 02:05 bmp
drwxr-xr-- 2 francois root   262144 jan 12 02:05 dll
drwxr-xr-- 2 francois root     4096 jan 12 01:54 doc
drwxr-xr-- 2 francois root    36864 jan 12 02:05 docx
drwxr-xr-- 2 francois root    36864 jan 12 02:05 exe
drwxr-xr-- 2 francois root   962560 jan 12 02:05 gif
drwxr-xr-- 2 francois root  8876032 jan 12 02:05 htm
drwxr-xr-- 2 francois root    57344 jan 12 01:55 jar
drwxr-xr-- 2 francois root  6922240 jan 12 02:05 jpg
drwxr-xr-- 2 francois root     4096 jan 11 23:30 mbd
drwxr-xr-- 2 francois root    36864 jan 12 02:05 mov
drwxr-xr-- 2 francois root    16384 jan 12 02:00 mp4
drwxr-xr-- 2 francois root     4096 jan 12 01:45 mpg
drwxr-xr-- 2 francois root   245760 jan 12 02:05 ole
drwxr-xr-- 2 francois root  3121152 jan 12 02:05 pdf
drwxr-xr-- 2 francois root 25518080 jan 12 02:05 png
drwxr-xr-- 2 francois root     4096 jan 12 01:52 ppt
drwxr-xr-- 2 francois root     4096 jan 12 02:05 pptx
drwxr-xr-- 2 francois root     4096 jan 12 01:51 rar
drwxr-xr-- 2 francois root     4096 jan 11 23:30 rif
drwxr-xr-- 2 francois root     4096 jan 11 23:30 sdw
drwxr-xr-- 2 francois root    69632 jan 12 11:16 sx
drwxr-xr-- 2 francois root     4096 jan 11 23:30 sxc
drwxr-xr-- 2 francois root     4096 jan 11 23:30 sxi
drwxr-xr-- 2 francois root     4096 jan 12 01:39 sxw
drwxr-xr-- 2 francois root     4096 jan 11 23:30 vis
drwxr-xr-- 2 francois root    36864 jan 12 01:55 wav
drwxr-xr-- 2 francois root     4096 jan 12 01:24 wmv
drwxr-xr-- 2 francois root     4096 jan 11 23:30 xls
drwxr-xr-- 2 francois root    20480 jan 12 11:08 xlsx
drwxr-xr-- 2 francois root   618496 jan 12 02:05 zip

Mais il n'a pas trouvé comment ces milliers de fichiers se trouvaient là où ils n'ont rien à faire...

Cela fait, il a passé la commande rm -R *, après avoir vérifié qu'il était bien dans le bon répertoire (!), tout a disparu et mon disque SSD n'est plus occupé qu'à 57% (contre 97%, une minute plus tôt!):

Code:

root@francois-N240JU:~/.local/share/Trash/files/output# rm -R *
root@francois-N240JU:~/.local/share/Trash/files/output# ls
root@francois-N240JU:~/.local/share/Trash/files/output# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               3.9G       0  3.9G   0% /dev
tmpfs              787M    2.0M  786M   1% /run
/dev/nvme0n1p2     458G    245G  190G  57% /
tmpfs              3.9G       0  3.9G   0% /dev/shm
tmpfs              5.0M    4.0K  5.0M   1% /run/lock
tmpfs              3.9G       0  3.9G   0% /sys/fs/cgroup
/dev/loop0         128K    128K     0 100% /snap/bare/5
/dev/loop1         135M    135M     0 100% /snap/chromium/1926
/dev/loop2         135M    135M     0 100% /snap/chromium/1942
/dev/loop5          55M     55M     0 100% /snap/snap-store/558
/dev/loop3         153M    153M     0 100% /snap/skype/203
/dev/loop4         248M    248M     0 100% /snap/gnome-3-38-2004/87
/dev/loop6         153M    153M     0 100% /snap/skype/206
/dev/loop7         165M    165M     0 100% /snap/gnome-3-28-1804/161
/dev/loop8          44M     44M     0 100% /snap/snapd/15177
/dev/loop9          56M     56M     0 100% /snap/core18/2344
/dev/loop10         51M     51M     0 100% /snap/snap-store/547
/dev/loop11         62M     62M     0 100% /snap/core20/1376
/dev/loop12         56M     56M     0 100% /snap/core18/2284
/dev/loop13         95M     95M     0 100% /snap/slack/60
/dev/loop14         66M     66M     0 100% /snap/gtk-common-themes/1519
/dev/loop15        249M    249M     0 100% /snap/gnome-3-38-2004/99
/dev/loop16        193M    193M     0 100% /snap/signal-desktop/379
/dev/loop17        219M    219M     0 100% /snap/gnome-3-34-1804/77
/dev/loop18        324M    324M     0 100% /snap/telegram-desktop/3544
/dev/loop19         83M     83M     0 100% /snap/whatsdesk/28
/dev/loop20         62M     62M     0 100% /snap/core20/1361
/dev/loop21         66M     66M     0 100% /snap/gtk-common-themes/1515
/dev/loop22         44M     44M     0 100% /snap/snapd/14978
/dev/loop23        261M    261M     0 100% /snap/kde-frameworks-5-core18/32
/dev/loop24        324M    324M     0 100% /snap/telegram-desktop/3530
/dev/loop25        187M    187M     0 100% /snap/signal-desktop/383
/dev/loop26        177M    177M     0 100% /snap/krita/64
/dev/loop27        219M    219M     0 100% /snap/gnome-3-34-1804/72
/dev/loop28        130M    130M     0 100% /snap/slack/49
/dev/nvme0n1p1     511M    5.3M  506M   2% /boot/efi
tmpfs              787M     60K  787M   1% /run/user/1000

Je note donc le problème comme [Résolu], même si mon sauveur suppose que le programme qui les a créés va les recréer...

François Marthaler · 18 Mar 2022 12:39:47

Visiblement, pour l'instant, cela a l'air de jouer! Après redémarrage, je n'ai plus que 4.1 KB dans /root/.local/share/Trash/files/output:

Pourvu que ça dure!...

Eggman · 18 Mar 2022 21:29:06

L'informaticien de la Bonne Combine a fait ce qu'il fallait.

Je note donc le problème comme [Résolu], même si mon sauveur suppose que le programme qui les a créés va les recréer...

Sur ce coup là, non, pas du tout.

Je suis néanmoins curieux de comprendre comment la poubelle du root s'est effectivement remplie, même si je peux imaginer plusieurs scénarios crédibles.

François Marthaler · 20 Mar 2022 00:02:53

Bonsoir,

Je viens de relancer l'Analyseur d'utilisation des disques avec sudo baobab pour constaté que je n'ai toujours que 427,3 MB sur root.

Je me demande si ce problème n'est pas en lien avec les blocages rencontrés depuis décembre 2021 sur le BIOS (voir https://swisslinux.org/forum/viewtopic.php?id=6394), car il faut un certain temps pour écrire des dizaines de GB (ce que j'ai toujours interprété comme un plantage du système...). Je suis conforté dans cette idée, car je n'ai plus de problème depuis une dizaine de jours.

Cordialement.

François Marthaler · 06 Apr 2022 22:27:42

Bonsoir,

Je viens de relancer l'Analyseur d'utilisation des disques avec sudo baobab pour constaté que je n'ai toujours et encore que 427,3 MB sur root. Il semblerait donc que le programme qui avait généré ces centaines de GB de données dans la corbeille (Trash) de root ne pose plus problème ou a été désinstallé...

En revanche, les problèmes de blocage du démarrage sur l'écran du BIOS sont récurrents. Ce matin, il m'a fallu forcer l'extinction et redémarrer quatre fois pour pouvoir commencer à travailler. Alors que, ce soir, elle a démarré du premier coup (voir https://swisslinux.org/forum/viewtopic.php?id=6394). J'exclus donc toute relation entre ce problème de démarrage et la corbeille de root qui serait en cours de remplissage, comme imaginé ci-dessus.

Cordialement.

Swisslinux.org

− Le carrefour GNU/Linux en Suisse −

Recherche

Menu

Forum

Identification

Inscription

Langue

Le Forum

#1 11 Mar 2022 16:23:26

[Résolu], SSD 500 GB presque plein

Code:

#2 11 Mar 2022 18:20:40

Re: [Résolu], SSD 500 GB presque plein

Code:

#3 11 Mar 2022 18:28:54

Re: [Résolu], SSD 500 GB presque plein

Code:

#4 11 Mar 2022 18:34:16

Re: [Résolu], SSD 500 GB presque plein

Code:

#5 12 Mar 2022 07:48:58

Re: [Résolu], SSD 500 GB presque plein

Code:

#6 13 Mar 2022 17:19:26

Re: [Résolu], SSD 500 GB presque plein

Code:

#7 15 Mar 2022 19:37:02

Re: [Résolu], SSD 500 GB presque plein

#8 16 Mar 2022 10:14:03

Re: [Résolu], SSD 500 GB presque plein

Code:

#9 16 Mar 2022 20:33:10

Re: [Résolu], SSD 500 GB presque plein

Code:

Code:

Code:

Code:

#10 17 Mar 2022 21:49:04

Re: [Résolu], SSD 500 GB presque plein

Code:

Code:

Code:

#11 18 Mar 2022 12:18:42

Re: [Résolu], SSD 500 GB presque plein

Code:

Code:

#12 18 Mar 2022 12:39:47

Re: [Résolu], SSD 500 GB presque plein

#13 18 Mar 2022 21:29:06

Re: [Résolu], SSD 500 GB presque plein

#14 20 Mar 2022 00:02:53

Re: [Résolu], SSD 500 GB presque plein

#15 06 Apr 2022 22:27:42

Re: [Résolu], SSD 500 GB presque plein

Pied de page des forums