Je lis ce qui suit sur https://qastack.fr/superuser/582138/are … ts-of-tmp:

Le répertoire /tmp/ doit être disponible pour les programmes qui nécessitent des fichiers temporaires.

Les programmes ne doivent pas supposer que tous les fichiers ou répertoires dans / tmp sont conservés entre les invocations du programme.

/var/tmp/ a un objectif similaire , mais ne doit pas être supprimé lors du redémarrage.

Il n'est pas garanti que /tmp/ ou /var/tmp/ sont nettoyés régulièrement. Cela peut dépendre de votre distribution et de vos paramètres, bien que la plupart des systèmes effectuent de temps en temps un nettoyage. Voir le commentaire de mike.

Si vous devez supprimer un fichier dans /tmp , voyez d'abord si le fichier est en cours d'utilisation. Vous pouvez le faire facilement avec:

lsof /tmp/file_to_delete

Si vous avez le droit de le faire, cela affichera le processus qui détient le descripteur de ce fichier, comme le nom du processus, le PID et le type du fichier. Pour afficher vraiment tous les processus, ajoutez sudo ou exécutez en tant qu'utilisateur root.

lsof +D /tmp

vous montrera tous les fichiers /tmp et répertoires ci-dessous (+D) qui sont actuellement ouverts. Bien sûr, vous ne devez pas supprimer ces fichiers.

Malheureusement, je ne suis plus sur la machine distante et si Analyseur d'utilisation du disque ne montre pas ces fichiers, je pense que je n'aurai rien de plus...

J'ai encore trouvé cette discussion sur https://stackoverflow.com/questions/456 … n-var-tmp, qui recommande d'effectuer un sudo apt autoremove.

Mais il me semble que je l'avais fait par habitude.

Je reste perdu...

François Marthaler a écrit:

J'ai encore trouvé cette discussion sur https://stackoverflow.com/questions/456 … n-var-tmp, qui recommande d'effectuer un sudo apt autoremove.

Mais il me semble que je l'avais fait par habitude.

Je reste perdu...

Ça permet juste de gagner un peu de temps en supprimant les paquets installés par dépendance qui ne sont plus attachés à aucun autre paquet. Ça ne résoudra pas le problème.

En complément, voici ce que dit Moniteur système au niveau des Systèmes de fichiers:



En revanche, je n'ai vu aucun processus consommant beaucoup de ressources dans l'onglet Processus.

Je suis toujours aussi perdu...

François Marthaler a écrit:

Je viens de prendre la main sur la machine défectueuse et la commande sudo du -sch /var/tmp/* me renvoie les 9 fichiers  systemd-private... précédés de milliers de fichiers commençant par /var/tmp/cnijr...

Que donnent les commandes suivantes ?

ls -1 /var/tmp/cnijr* | wc -l 
du -sch /var/tmp/cnijr* | tail -n1
ls -lhtr  /var/tmp/cnijr* | tee >(head -n2) >(tail -n1) >/dev/null

Cela nous donnera un décompte de ces fichiers, leur taille totale, la date du plus ancien et du plus récent.

Note: évidemment, si les noms des fichiers cnijr* devaient changer, il faudrait adapter le chemin.

En fait, je ne sais pas ce qu'il s'est passé avec mon Ubuntu Software. La recherche de Firefox (installé) ne le trouvait pas et si, dans l'onglet Installés je cliquais sur un logiciel pour avoir des précisions, rien ne s'affichait.

J'ai effectué les mises à jour et redémarré le système. Comme Ubuntu Software trouvait à nouveau Firefox comme logiciel installé, j'ai recherché et installé bleachbit. J'ai maintenant deux versions, dont une (as root) que je vais privilégier.

Au lancement, BeachBit s'ouvre sur les Préférences. J'en ai ajouté quelques-unes qui me semblaient pertinentes:



Comme cela ne me parlait pas, je n'ai rien modifié aux onglets Personnalisé, Lecteurs, Langues et Liste blanche.

Comme le problème de notre cliente se situe dans /var/tmp (comme temporaire), j'ai coché Fichiers temporaires dans la liste Analyse approfondie et accepté la suppression des fichiers:



L'opération s'est effectuée en 1 seconde et BleachBit s'est arrêté, comme demandé dans les préférences.

J'ai relancé BleachBit (as root), décoché dans Préférences Quitter après le nettoyage, pour avoir le résultat de l'opération:



Évidemment, comme je venais de faire un nettoyage, je n'ai pas gagné de place, mais j’espère que notre cliente récupérera ses 127 GB...

Eggman a écrit:

Que donnent les commandes suivantes ?

Notre cliente a pu passer les commandes proposées et nous a voyé une capture d'écran:



J'en déduis qu'il y a 1248 fichiers cnijr* totalisant 114 GB et que le premier et le dernier datent tous du 22.11.2021.

Ne reste plus qu'à savoir s'ils peuvent être supprimés et surtout qu'est-ce qui les génère...

François Marthaler a écrit:

Notre cliente a pu passer les commandes proposées et nous a voyé une capture d'écran:

https://blog.whyopencomputing.ch/wp-con … 313907.png

J'en déduis qu'il y a 1248 fichiers cnijr* totalisant 114 GB et que le premier et le dernier datent tous du 22.11.2021.

Ne reste plus qu'à savoir s'ils peuvent être supprimés et surtout qu'est-ce qui les génère...

Ok. Résumons:
- ce sont bien les fichiers /var/tmp/cnijr* qui posent problème et remplissent le disque, vu leur nombre et leur taille
- les fichiers semblent générés ou au moins rafraîchis à chaque démarrage vu les dates
- ils appartiennent à l'utilisateur lp, soit le gestionnaire d'impression.

Donc pour une raison inconnue, le gestionnaire d'impression remplit /var/tmp.
Je ne sais pas s'il y a des jobs d’impression en attente ou autre, mais il faut regarder de ce côté.

Merci Eggman!

Le nom de ces fichiers cnijr* pourrait bien indiquer "Canon". Je vais poser la question à notre cliente...

J'imagine que la commande pour les supprimer est:

sudo rm /var/tmp/cnijr*

Reste à savoir s'ils seront recréés dans la foulée...

Cordialement.

Pour celles et ceux qui souhaitent en savoir plus sur la commande du, voici les explications complètes: https://linuxhandbook.com/find-director … -command/.

En complément, on peut aussi s'intéresser à la commande df: https://linuxhandbook.com/df-command/.

Bonne lecture.