La semaine dernière la secrétaire d’accueil de notre lycée local m’a appelé pour attirer mon attention sur un problème avec son poste de travail Linux. Une notification lui indique que le disque dur est plein et qu’elle ne peut plus rien faire.
Sur le coup j’étais un peu perplexe et vaguement inquiet. Toutes les données des utilisateurs de l’école sont centralisées sur un partage NFS avec une grappe RAID dimensionnée de façon assez généreuse. Que s’est-il donc passé ?
Après vérification, ce n’était pas l’export NFS monté sur /home qui posait problème. Une petite recherche à coups de du -sh me montre que le problème se situe visiblement dans le répertoire /var/tmp. Un véritable tsunami de fichiers cnijtrucmuche qui remplit le disque :
# ls -lhS /var/tmp/
-rw-------. 1 lp lp 94M Nov 23 10:34 cnijrawtmp1BcQoD
-rw-------. 1 lp lp 94M Nov 27 10:24 cnijrawtmp1CSfHF
-rw-------. 1 lp lp 94M Nov 27 10:25 cnijrawtmp2LNxVc
-rw-------. 1 lp lp 94M Nov 27 10:13 cnijrawtmp4GYlfU
-rw-------. 1 lp lp 94M Nov 27 10:24 cnijrawtmp4Oy17X
-rw-------. 1 lp lp 94M Nov 27 10:28 cnijrawtmp67RIPc
-rw-------. 1 lp lp 94M Nov 27 10:23 cnijrawtmp795ldC
-rw-------. 1 lp lp 94M Nov 23 10:36 cnijrawtmp8IS8qR
-rw-------. 1 lp lp 94M Nov 23 10:39 cnijrawtmp98mbRJ
-rw-------. 1 lp lp 94M Nov 27 10:23 cnijrawtmp9AQPxm
-rw-------. 1 lp lp 94M Nov 27 10:21 cnijrawtmp9OSb62
-rw-------. 1 lp lp 94M Nov 23 10:39 cnijrawtmp9XUUq0
-rw-------. 1 lp lp 94M Nov 23 10:35 cnijrawtmpC2Gu7R
-rw-------. 1 lp lp 94M Nov 27 10:30 cnijrawtmpcC5MvM
-rw-------. 1 lp lp 94M Nov 27 10:25 cnijrawtmpCNFL0N
-rw-------. 1 lp lp 94M Nov 27 10:21 cnijrawtmpCP54k6
-rw-------. 1 lp lp 94M Nov 27 10:23 cnijrawtmpdYGFDA
-rw-------. 1 lp lp 94M Nov 27 10:29 cnijrawtmpECzW5I
-rw-------. 1 lp lp 94M Nov 27 10:29 cnijrawtmpeJVR9g
-rw-------. 1 lp lp 94M Nov 23 10:34 cnijrawtmpeYgo2U
-rw-------. 1 lp lp 94M Nov 27 10:22 cnijrawtmpGHYV23
...
Après quelques recherches sur Google et dans les forums, il semblerait bien que ces fichiers soient générés par notre nouvelle imprimante Canon. Plus concrètement, chaque page imprimée se solde par la génération d’un fichier temporaire de 94 Mo dans /var/tmp, sauf que ce fichier temporaire n’est pas nettoyé après l’impression.
Certes, 94 Mo ce n’est pas beaucoup. Or, tous les postes clients de l’école sont dotés de petits disques SSD de 60 Go censés contenir le seul système d’exploitation. Étant donné que l’imprimante est pas mal sollicitée, le disque aura mis un peu moins de deux mois à se remplir.
Pour résoudre le problème dans l’immédiat, il suffit de supprimer tout simplement tous ces fichiers :
# rm -f /var/tmp/cnij*
Et pour faire le ménage à l’avenir, on va mettre en place une tâche automatique :
# crontab -e
# Clean up printer files
@reboot find /var/tmp -name 'cnij*' -exec rm -f {} \;
Ici, la directive @reboot lance le cronjob au redémarrage du système, et le problème est réglé.
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
7 commentaires
Jonathan · 12 décembre 2023 à 18 h 57 min
C’est bon à savoir. Merci pour ce retour d’expérience.
lszr · 13 décembre 2023 à 13 h 51 min
Bonjour,
Il est aussi possible, sous réserve d’avoir assez de mémoire, mettre /tmp (&Co) dans un tmpfs c’est plus rapide, ça n’écrit pas sur le SSD et c’est vidé automatiquement à l’arrêt.
kikinovak · 13 décembre 2023 à 14 h 58 min
Oui, mais ce n’est pas
/tmpmais/var/tmp, et ce dernier n’est pas censé être vidé au redémarrage d’après les recommandations du FHS.lszr · 14 décembre 2023 à 22 h 21 min
Bonsoir,
Oups, je n’avais pas lu la FHS, je ne savais pas concernant /var/tmp, merci, j’ai appris quelque chose, mais personnellement, je ne compterais pas sur ce comportement. Pour ma part j’ai un /var/local/tmp, qui est un tmpfs et la valeur par défaut de TMPDIR.
En regardant les sources qui sont fournies (doivent permettre de compiler le driver et le programme de numérisation), on voit effectivement des appels à mkstemp() avec des chaînes hardcodées:
./cnijfilter2-source-6.20-1/tocnpwg/src/main.c
#define CNIJPWG_TEMP « /var/tmp/cnijpwgtmpXXXXXX »
#define CNIJRAW_TEMP « /var/tmp/cnijrawtmpXXXXXX »
./scangearmp2-source-4.20-1/scangearmp2/src/file_control.c
#define TEMP_FILE_FULL_NAME « /var/tmp/cnms_tmp_file_XXXXXX\0 »
sans qu’il n’y ait de suppression après usage (j’ai survolé le code, j’ai pu loupé).
Il manque la vérification du retour de mkstemp() à au moins un appel.
Donc les programmes n’honorent pas TMPDIR, pas moyen de passer par là.
Il me semble néanmoins que c’est utilisé uniquement en interne, et pas accédé depuis le système de fichier, donc la réponse acceptée à la question 32445579 de Stack Overflow, dont je copie la partie qui nous intéresse, s’applique:
« You need to call unlink on the file manually. You can do this immediately after calling mkstemp if you don’t need to access the file by name (i.e. via the file system) — it will then be deleted once the descriptor is closed. »
Il suffirait d’ajouter 3 appels à unlink(), avec la bonne variable, après chaque mkstemp() réussi, et de recompiler, pour en quelque sorte, résoudre le problème à la source.
La compilation n’est peut-être pas si simple, mais en tout cas, vu la provenance, ça ne devrait pas être écrasé de si tôt par une mise à jour.
Après, on peut aussi utiliser un fichier cron.
J’ajouterais si besoin les fichiers cnms_tmp_file_* (après un scan, en reste-t-il dans /var/tmp/?) et regarderais si le find possède l’option « -delete », que je privilégie, en prenant bien garde à l’ordre des arguments (le manuel prévient clairement des risques).
kikinovak · 14 décembre 2023 à 22 h 44 min
Joli travail de détective. Pour ma part, j’évite ce genre de problème en amont puisqu’en règle générale j’évite d’acheter des imprimantes Canon au vu de leur support Linux notoirement calamiteux. Cette Canon était un cadeau pour l’école, et c’est l’histoire du cheval donné auquel on ne regarde pas les dents. Perso je préfère HP qui fournit des pilotes qui JusteMarchent(tm).
Quentin · 13 décembre 2023 à 19 h 03 min
C’est un comportement très particulier, je me demande la raison pour laquelle il ne fait pas ce nettoyage.
Plutôt qu’une Crontab, j’aurai plutôt mis un tmpfs. Qu’en penses-tu ?
Merci pour ce REX !
kikinovak · 13 décembre 2023 à 20 h 02 min
J’y ai répondu dans l’autre commentaire. Selon le FHS,
/tmppeut être vidé au redémarrage, contrairement à/var/tmpqui est susceptible de contenir des choses qui doivent persister après un redémarrage.