augmenetation taille /tmp
Le
Jean-Michel OLTRA
Bonjour,
L'occupation de ma partition montée sur /tmp augmente régulièrement.
C'est un volume logique. Il y a une semaine ou deux, elle avait conservé
sa taille initiale (100M). J'ai du la remonter à 500, puis 800 hier
soir, avec actuellement une occupation (au sens de df) de 560M. Hier
soir, lorsque j'ai stoppé la machine, j'avais 496M. Donc 64M de mieux au
reboot, si je puis dire. Évidemment, un `du -sh /tmp` ne donne quasiment
rien.
Un `lsof -a +L1` sur /tmp ne donne quasiment rien, que des fichiers
apache2 ou mysqld. L'arrêt de ces services ne rend rien de probant, et
surtout pas de l'espace disque.
Avant de stopper la machine, j'ai tenté, hier soir, de me mettre sur le
terminal, couper X et un certain nombre de services (postfix, mysql,
apache, cron, clamav, nut, dnsmasq, memcached, libvirt). Sans succès.
Une idée pour un meilleur diagnostic ?
Merci.
--
jm
L'occupation de ma partition montée sur /tmp augmente régulièrement.
C'est un volume logique. Il y a une semaine ou deux, elle avait conservé
sa taille initiale (100M). J'ai du la remonter à 500, puis 800 hier
soir, avec actuellement une occupation (au sens de df) de 560M. Hier
soir, lorsque j'ai stoppé la machine, j'avais 496M. Donc 64M de mieux au
reboot, si je puis dire. Évidemment, un `du -sh /tmp` ne donne quasiment
rien.
Un `lsof -a +L1` sur /tmp ne donne quasiment rien, que des fichiers
apache2 ou mysqld. L'arrêt de ces services ne rend rien de probant, et
surtout pas de l'espace disque.
Avant de stopper la machine, j'ai tenté, hier soir, de me mettre sur le
terminal, couper X et un certain nombre de services (postfix, mysql,
apache, cron, clamav, nut, dnsmasq, memcached, libvirt). Sans succès.
Une idée pour un meilleur diagnostic ?
Merci.
--
jm
:
âsoir,
Quâest ce que tu entends par « volume logique » ? U n LV de
LVM ?
Tu penses que ça peut être un facteur ?
Bon, à partir dâici, je vais reformuler pour vérifi er que lâon
comprend bienâ¦
Autrement dit, la partition se remplit mais aucun fichier
nâapparaît prendre cet espace.
Dâoù lâidée de chercher des fichiers effacà ©s mais toujours lÃ
avec lsof :
Donc les fichiers en cours mais effacés ne semblent pas êtr e
ceux qui prennent de lâespace.
Et arrêter les suspects habituels ne libère pas lâe space
disque qui, je suppose, nâest toujours pas rendu et nâe st
toujours dans aucun répertoire�
Je suppose que tu as vérifié que lâespace utilisà © grossit
toujours même sans les services ?
Et si tu réduits la taille de la partition et que tu attends
que quelquâun plante ?
Et quel est le FS ?
--
Sylvain Sauvage
On 19/09/2015 19:22, Sylvain L. Sauvage wrote:
Honnêtement c'est vraiment super bizarre qu'après un reboot il
y ait encore un /tmp bien rempli. Car des fichiers non visibles
dans /tmp mais toujours présents parce qu'il y a des processus
qui lisent ou écrivent encore dedans, ça d'accord, mais après
un reboot je ne vois pas comment ça peut persister (vu que les
processus sont morts et donc les fichiers sont définitivement
perdus, l'espace est considéré comme disponible par le fs).
Personnellement, je ne comprends pas qu'un reboot n'ait pas résolu
ce problème.
--
François Lafont
Le samedi 19 septembre 2015, Sylvain L. Sauvage a écrit...
C'est bien un LV de LVM.
Et je commence à me dire que c'est peut-être un facteur.
Oui.
Oui.
Exact, ça ne change rien. Certains fichiers marqués comme (deleted)
disparaissent (apache, mysqld). Mais ça n'apporte rien.
Non. J'ai stoppé la machine ensuite. L'espace utilisé ne grossit pas en
fonctionnement. J'ai l'impression que ça grossit au démarrage de
session. La première fois (et la seconde…, mais là je savais où taper),
le symptôme le plus immédiat fut que X n'était pas lancé au boot (mais
gdm3 tournait toujours). En fait, juste pour l'anecdote, j'ai pu le
relancer via un `service gdm3 restart`, mais je me suis retrouvé avec
une drôle de configuration clavier sous X, puis avec un souci sous
aptitude (suppression d'image noyau obsolète).
Je pourrais essayer, mais je n'y crois guère, puisque rien n'écrit
dedans si je ne fais rien. Sauf X au démarrage, puis des choses comme
aptitude comme dit plus haut.
xfs
/dev/mapper/debian-lvtmp on /tmp type xfs (rw,relatime,inode64,noquota)
Je reviens sur la configuration en volume comme facteur. Je me dis que
si je ne vois rien concernant le système de fichiers (fichiers effacés
mais toujours ouverts par exemple), c'est peut-être que l'augmentation
est due à des metadonnées de lvm2. J'ai posté il y a quelques semaines un
souci avec lvm2 et le nouveau noyau 4. Celui ci a été corrigé, mais y
aurait il un bogue résiduel ?
Je viens d'enregistrer les sorties de `df` et `df -h`. J'ai d'autres
volumes logiques sur ce raid logiciel, un qui couvre /usr, et un autre
sur un home utilisateur qui n'est plus utilisé. Je vais voir si ceux ci
grossissent également. La suite demain, donc.
--
jm
Le samedi 19 septembre 2015, Francois Lafont a écrit...
Non seulement ça ne le résoud pas, mais en plus ça fait empirer le
phénomène, puisque mon volume monté sur /tmp s'est pris 64M après le
reboot !
--
jm
La seule explication possible que je vois à un truc pareil c'est que
tu as un processus (ou plusieurs) qui est lancé au démarrage du système
qui t'écrit plein de trucs dans /tmp et cela avant même le vidage
de /tmp qui lui aussi s'effectue à chaque démarrage du système.
Pour moi, un fichier qui prend de la place dans le fs mais qu'on ne
voit plus dans l'arborescence, c'est forcément un fichier utilisé
par un processus, je ne vois pas comment il peut en être autrement
(où alors un fs en vrac peut-être).
Perso, à ta place je tenterais ceci :
# apt-get install lsof
lsof | grep /tmp/
Sauf erreur, ça devrait t'afficher la liste de tous les
processus qui utilisent un fichier dans /tmp/ *même* si
celui-ci n'existe plus dans l'arborescence.
À tester donc...
PS : j'ose à peine te le demander mais bon juste au cas où : tu
as bien sûr fait un `ls -al /tmp` pour afficher aussi les fichiers
« cachés », n'est-ce pas ? ;)
--
François Lafont
J'avais un système de captcha qui écrivait contnuellement dans tmp
Ce serait peut-être intéressant de voir ce qu'il y a dedans lorsqu'il démarre ?
Le dimanche 20 septembre 2015, Francois Lafont a écrit...
Confirmé !
Le volume monté sur /tmp s'est pris 32M au reboot
Le volume inutilisé monté sur /home/laurena (ancien montage nfs pour
l'ordi de ma fille), s'est également pris 32M.
Le volume monté sur /usr est plus gros, donc on ne voit pas la
différence avec `df -h`, mais avec df tout court : +23128 blocs de 1k.
A ce rythme là, je vais bientôt avoir de gros soucis…
J'ai déjà parlé de lsof. Je donne les résultats ci après :
espinasse:~$ fuser -v -m /tmp/
UTIL. PID ACCÈS COMMANDE
/tmp: root kernel mount /tmp
mysql 1598 F.... mysqld
root 1613 F.... Xorg
root 1712 F.... apache2
jm 2126 F.... ssh-agent
www-data 6504 F.... apache2
www-data 6505 F.... apache2
www-data 6506 F.... apache2
www-data 6507 F.... apache2
www-data 6508 F.... apache2
espinasse:~$ lsof /tmp
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mysqld 1598 mysql 5u REG 253,1 0 135 /tmp/ibQZHR5l (deleted)
mysqld 1598 mysql 6u REG 253,1 101 136 /tmp/ibaQ1rC0 (deleted)
mysqld 1598 mysql 7u REG 253,1 0 137 /tmp/ibIoH28E (deleted)
mysqld 1598 mysql 8u REG 253,1 0 138 /tmp/ibuX4pgY (deleted)
mysqld 1598 mysql 12u REG 253,1 0 139 /tmp/ibT8zJyG (deleted)
apache2 1712 root 10u REG 253,1 0 132 /tmp/.ZendSem.AEtmFA (deleted)
apache2 6504 www-data 10u REG 253,1 0 132 /tmp/.ZendSem.AEtmFA (deleted)
apache2 6505 www-data 10u REG 253,1 0 132 /tmp/.ZendSem.AEtmFA (deleted)
apache2 6506 www-data 10u REG 253,1 0 132 /tmp/.ZendSem.AEtmFA (deleted)
apache2 6507 www-data 10u REG 253,1 0 132 /tmp/.ZendSem.AEtmFA (deleted)
apache2 6508 www-data 10u REG 253,1 0 132 /tmp/.ZendSem.AEtmFA (deleted)
Juste après l'ouverture de la session X :
espinasse:~$ la /tmp/
total 12
drwxrwxrwt 12 root root 4096 sept. 20 10:39 .
drwxr-xr-x 24 root root 4096 sept. 11 12:03 ..
drwxrwxrwt 2 root root 6 sept. 20 10:05 .font-unix
drwxrwxrwt 2 root root 17 sept. 20 10:07 .ICE-unix
drwx------ 2 jm jm 6 janv. 1 1970 orbit-jm
drwx------ 2 root root 6 sept. 20 10:05 pulse-PKdhtXMmr18n
drwx------ 2 jm jm 23 sept. 20 10:10 ssh-ZTEyLQglrWVt
drwx------ 3 root root 16 sept. 20 10:07 systemd-private-b08106bc4793424f806ac0ea7c1752b3-tor.service-OJOe56
drwxrwxrwt 2 root root 6 sept. 20 10:05 .Test-unix
drwx------ 2 jm jm 6 sept. 20 10:31 vXp3d2e
-r--r--r-- 1 root root 11 sept. 20 10:07 .X0-lock
drwxrwxrwt 2 root root 15 sept. 20 10:07 .X11-unix
drwxrwxrwt 2 root root 6 sept. 20 10:05 .XIM-unix
Mais il ne semble pas que ce soit lié à /tmp, en définitive.
Le volume monté sur /usr semble avoir subi une augmentation de taille
inférieure, environ 24M, et je ne pense pas qu'un processus écrive
dedans également.
Le volume monté sur /home/laurena est _totalement_ inutilisé, lui, mais
il s'est pris 32M. Je me dis donc que l'occupation disque est bas niveau
et invisible au système de fichiers.
--
jm
Tu peux afficher les sorties de df ?
--
Fabien
écrit :
âjour,
Et des snapshots LVW au boot ?
Bon, il faudrait que la taille dâun instantané « vi de » soit
de 32 Mo pour le /home/laurena, et ça me paraît beaucoup⠦
--
Sylvain Sauvage
écrit :
Remarque, il nâest peut-être pas vide sâil est aus si monté avec
relatime et quâune lecture complète est faite (locate ou a utre).
--
Sylvain Sauvage