Re: augmenetation taille /tmp

[andre_debian]

On Wednesday 30 September 2015 12:21:16 Jean-Michel OLTRA wrote:
> Mon volume monté sur /tmp ne bouge pas. Toujours 33M, ce qui est trop,
> mais stable.

Chez moi, suivant mes PC et le moment, 
il fait entre 12Ko et 304Ko...

Re: augmenetation taille /tmp

[BERBAR Florian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/09/2015 12:21, Jean-Michel OLTRA wrote:
> Si je te suis bien, je compare entre les 2 versions, si je le peux,
> car il y en a pas mal, les blocks marqués comme "setting block X/Y
> to data" ?

Oui je pense que cela être intéressant à tester.

Je pense qu'en redirigeant la sortie de xfs_db dans un fichiers, tu
pourra utiliser un utilitaire comme "diff" sur les deux versions que
tu auras obtenu. Les différences obtenu entre les fichiers seront les
blocks qui auront changé.

Bon courage,

Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWDEUUAAoJEBGYNnE0a7qPcAcQAIesDtJ/SXGzzRy7D0xlsRlj
3QMnwsEf3MAeLP4iAjqUZeELt/+RV3Ph/D5tRzR6GAOG9tD8hj6yb9AYb6BaoACK
S2fbEGN0PX5Re4IAMep9R8A+suN6mjYKwkyIiqkJbi2mJCh9OHO5RHOU852mofDj
sRiE+xnxmkH+Z3Pgt7ROvec4okHQg4t4XhtzjcMSVFG8GKtf6dleCPUE7YgsOrh9
bVDb4bJPEzJIXYwVapUQJfRP+SaSkCbV7aw9W6/JnIJkZ/NjDhcAgYRfpPToyleL
dgNtmK5Ck3w3loHRw1sNAKfuYrSUeD3STz03tCwwLaAppp8c7aGhISQr91NS/O3C
1EJDBA/vQp0ub62qnp6mQDKcPfhz62n6qu3cZXQAWBCRO6nFNjWfic69iG9Rtto8
2T3sO8BgQvxCuQEmRZ0HRoh5GECzkuGrtobs+1k6TgqIo+i5WvSKCkh1wEv3Yc3y
QHCJN9RyDnb06nWQOOXW3lfPccOZU8yXGPLqZ4eoE1Gr1rzX4XE90N7gMmiamAp5
0165Joy8TiQpmSusUz7f8uuPzahKTkQMYEd35rSFPj4/vUfa45Krdz+IT+aLl6LI
3TkNTVMAwnhFELuOnzGRno/utWFoLvJuOzuSq5wiz70ibOY2HKRnb74SpxHukQjG
+kZRevqf0NaKogRKy7Eo
=tXqP
-END PGP SIGNATURE-

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le jeudi 24 septembre 2015, BERBAR Florian a écrit...


> Le sortie de la commande "xfs_db -c 'blockget -v -p' /dev/tondevice"
> devrais ressembler à quelque chose comme :

> "/dev/tondevice: setting block / to  ou
> "

> Au sujet des informations de chaque block de ton volume (identifier
> par "/") : Un espace contenant un donnée  ou un
> espace libre .

> "/dev/tondevice: setting inode to  for block /"

> Au sujet des information (meta-information) relative a un block de
> données.

> L'idée était de cerner quel block était libre et quel block était
> occuper par des données et de par ce fait voir quel block est a changé
> d'état lors de l'accroissement de la taille de ta partition. Ainsi
> nous aurions pus connaître un identifiant de block pointant sur un
> zone fraîchement occuper par l'accroissement taille de ton volume puis
> lire les données qu'il contient afin d'en connaître l'origine.

Mon volume monté sur /tmp ne bouge pas. Toujours 33M, ce qui est trop,
mais stable.

En revanche le volume monté sur /home/laurena s'est pris 64M. J'ai fait
un xfs_db pour récupérer les données et pour comparer avec ce que
j'avais pris avant.

Si je te suis bien, je compare entre les 2 versions, si je le peux, car
il y en a pas mal, les blocks marqués comme "setting block X/Y to
data" ?

-- 
jm

Re: augmenetation taille /tmp

[BERBAR Florian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/09/2015 07:07, Jean-Michel OLTRA wrote:
> 
> Bonjour,
> 
> 
> Le mardi 22 septembre 2015, BERBAR Florian a écrit...
> 
> 
>> Pourrais-tu préciser les options que tu as passer à l'utilitaire 
>> "xfs_repair" ? D'autre part, si cela n'as pas été le cas lors de
>> ta dernier utilisation de l'utilitaire "xfs_repair", pourrais-tu
>> donner la sortie de la commande en ajoutant l'option "-v" qui
>> permet de d'activer une sortie un peu plus bavarde ?
> 
> Voilà pour xfs_repair sur le VL monté sur /tmp
> 
> Phase 1 - find and verify superblock... - block cache size set to
> 567104 entries Phase 2 - using internal log - zero log... zero_log:
> head block 6 tail block 6 - scan filesystem freespace and inode
> maps... - found root inode chunk Phase 3 - for each AG... - scan
> and clear agi unlinked lists... - process known inodes and perform
> inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 -
> process newly discovered inodes... Phase 4 - check for duplicate
> blocks... - setting up duplicate extent list... - check for inodes
> claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 -
> agno = 3 Phase 5 - rebuild AG headers and trees... - agno = 0 -
> agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 -
> check inode connectivity... - resetting contents of realtime bitmap
> and summary inodes - traversing filesystem ... - agno = 0 - agno =
> 1 - agno = 2 - agno = 3 - traversal finished ... - moving
> disconnected inodes to lost+found ... Phase 7 - verify and correct
> link counts...
> 
> XFS_REPAIR SummaryThu Sep 24 06:54:31 2015
> 
> Phase   Start   End Duration Phase 1:09/24 06:54:30
> 09/24 06:54:30 Phase 2:09/24 06:54:30  09/24 06:54:31  1
> second Phase 3:09/24 06:54:31  09/24 06:54:31 Phase 4:09/24
> 06:54:31  09/24 06:54:31 Phase 5:09/24 06:54:31  09/24 06:54:31
>  Phase 6:09/24 06:54:31  09/24 06:54:31 Phase 7:09/24
> 06:54:31  09/24 06:54:31
> 
> Total run time: 1 second done
> 
>> # xfs_db -c 'blockget -v -p' /dev/tondevice
> 
> Ne donne rien sur le VL monté sur /tmp. Pas de sortie.

A mes yeux c'est bizarre que cette commande de renvoie rien. Le volume
était bien démonté ?

> 
> Pour mon autre volume, c'est quand même un peu trop gros pour
> mettre sur la liste. Et je ne sais pas vraiment ce qu'il faut
> chercher dedans.

Le sortie de la commande "xfs_db -c 'blockget -v -p' /dev/tondevice"
devrais ressembler à quelque chose comme :

"/dev/tondevice: setting block / to  ou
"

Au sujet des informations de chaque block de ton volume (identifier
par "/") : Un espace contenant un donnée  ou un
espace libre .

"/dev/tondevice: setting inode to  for block /"

Au sujet des information (meta-information) relative a un block de
données.

L'idée était de cerner quel block était libre et quel block était
occuper par des données et de par ce fait voir quel block est a changé
d'état lors de l'accroissement de la taille de ta partition. Ainsi
nous aurions pus connaître un identifiant de block pointant sur un
zone fraîchement occuper par l'accroissement taille de ton volume puis
lire les données qu'il contient afin d'en connaître l'origine.

> 
> Un `df -h` hier soir avant extinction :
> 
> Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur 
> udev10M   0   10M   0% /dev tmpfs
> 1,2G 24M  1,2G   2% /run /dev/md2   5,4G
> 1,1G  4,1G  21% / /dev/dm-0   30G 13G   18G
> 42% /usr tmpfs  3,0G 12K  3,0G   1%
> /dev/shm tmpfs  5,0M4,0K  5,0M   1%
> /run/lock tmpfs  3,0G   0  3,0G   0%
> /sys/fs/cgroup /dev/md088M 36M   47M
> 44% /boot /dev/mapper/debian-lvvar50G 17G   34G  34%
> /var /dev/mapper/debian-lvhome   60G 50G   11G  83% /home 
> /dev/mapper/debian-lvtmp   797M 33M  765M   5% /tmp 
> /dev/mapper/debian-lvlaurena   2,0G901M  1,2G  45%
> /home/laurena tmpfs  598M4,0K  598M
> 1% /run/user/1000 tmpfs  598M   0  598M
> 0% /run/user/0
> 
> Un `df -h` ce matin après xfs_repair sur /tmp et /home/laurena :
> 
> 
> Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur 
> udev10M   0   10M   0% /dev tmpfs
> 1,2G9,0M  1,2G   1% /run /dev/md2   5,4G
> 1,2G  4,0G  22% / /dev/dm-0   30G 13G   18G
> 42% /usr tmpfs  3,0G 12K  3,0G   1%
> /dev/shm tmpfs  5,0M4,0K  5,0M   1%
> /run/lock tmpfs  3,0G   0  3,0G   0%
> /sys/fs/cgroup /dev/md088M 36M   47M
> 44% /boot /dev/mapper/debian-lvhome   60G 50G   11G  84%
> /home /dev/mapper/debian-lvvar50G 17G   34G  34% /var 
> tmpfs 

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le mardi 22 septembre 2015, BERBAR Florian a écrit...


> Pourrais-tu préciser les options que tu as passer à l'utilitaire
> "xfs_repair" ? D'autre part, si cela n'as pas été le cas lors de ta
> dernier utilisation de l'utilitaire "xfs_repair", pourrais-tu donner
> la sortie de la commande en ajoutant l'option "-v" qui permet de
> d'activer une sortie un peu plus bavarde ?

D'accord, je recommencerai. Le truc c'est que, ce matin, pas
d'augmentation…

> Toujours au sujet de ton système de fichier xfs, as tu tenté
> d'examiner les volumes toucher par ton problème d'accroissement de
> taille avec les utilitaire "xfs_io" ou "xfs_db" qui permet de déboguer
> un système de fichier XFS.

> Par exemple :

> # xfs_db -c 'blockget -v -p' /dev/tondevice

J'essaierai xfs_db juste avant, et juste après le reboot.

Savoir si je saurai interpréter la sortie est une autre histoire…

Merci de ton aide.


-- 
jm

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le mardi 22 septembre 2015, BERBAR Florian a écrit...


> Pourrais-tu préciser les options que tu as passer à l'utilitaire
> "xfs_repair" ? D'autre part, si cela n'as pas été le cas lors de ta
> dernier utilisation de l'utilitaire "xfs_repair", pourrais-tu donner
> la sortie de la commande en ajoutant l'option "-v" qui permet de
> d'activer une sortie un peu plus bavarde ?

Voilà pour xfs_repair sur le VL monté sur /tmp

Phase 1 - find and verify superblock...
- block cache size set to 567104 entries
Phase 2 - using internal log
- zero log...
zero_log: head block 6 tail block 6
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...

XFS_REPAIR SummaryThu Sep 24 06:54:31 2015

Phase   Start   End Duration
Phase 1:09/24 06:54:30  09/24 06:54:30  
Phase 2:09/24 06:54:30  09/24 06:54:31  1 second
Phase 3:09/24 06:54:31  09/24 06:54:31  
Phase 4:09/24 06:54:31  09/24 06:54:31  
Phase 5:09/24 06:54:31  09/24 06:54:31  
Phase 6:09/24 06:54:31  09/24 06:54:31  
Phase 7:09/24 06:54:31  09/24 06:54:31  

Total run time: 1 second
done

> # xfs_db -c 'blockget -v -p' /dev/tondevice

Ne donne rien sur le VL monté sur /tmp. Pas de sortie.

Pour mon autre volume, c'est quand même un peu trop gros pour mettre sur 
la liste. Et je ne sais pas vraiment ce qu'il faut chercher dedans.

Un `df -h` hier soir avant extinction :

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev10M   0   10M   0% /dev
tmpfs  1,2G 24M  1,2G   2% /run
/dev/md2   5,4G1,1G  4,1G  21% /
/dev/dm-0   30G 13G   18G  42% /usr
tmpfs  3,0G 12K  3,0G   1% /dev/shm
tmpfs  5,0M4,0K  5,0M   1% /run/lock
tmpfs  3,0G   0  3,0G   0% /sys/fs/cgroup
/dev/md088M 36M   47M  44% /boot
/dev/mapper/debian-lvvar50G 17G   34G  34% /var
/dev/mapper/debian-lvhome   60G 50G   11G  83% /home
/dev/mapper/debian-lvtmp   797M 33M  765M   5% /tmp
/dev/mapper/debian-lvlaurena   2,0G901M  1,2G  45% /home/laurena
tmpfs  598M4,0K  598M   1% /run/user/1000
tmpfs  598M   0  598M   0% /run/user/0

Un `df -h` ce matin après xfs_repair sur /tmp et /home/laurena :


Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev10M   0   10M   0% /dev
tmpfs  1,2G9,0M  1,2G   1% /run
/dev/md2   5,4G1,2G  4,0G  22% /
/dev/dm-0   30G 13G   18G  42% /usr
tmpfs  3,0G 12K  3,0G   1% /dev/shm
tmpfs  5,0M4,0K  5,0M   1% /run/lock
tmpfs  3,0G   0  3,0G   0% /sys/fs/cgroup
/dev/md088M 36M   47M  44% /boot
/dev/mapper/debian-lvhome   60G 50G   11G  84% /home
/dev/mapper/debian-lvvar50G 17G   34G  34% /var
tmpfs  598M4,0K  598M   1% /run/user/1000
/dev/sdd1   31G8,3G   22G  28% /mnt/usbstick
/dev/mapper/debian-lvtmp   797M 33M  765M   5% /mnt/tmp
/dev/mapper/debian-lvlaurena   2,0G837M  1,2G  42% /home/laurena

On voit que le xfs_repair a regagné 64M sur le VL monté sur
/home/laurena.

Et le `du -sh` du VL de /tmp :

espinasse:~$ mount /dev/mapper/debian-lvtmp /mnt/tmp
espinasse:~$ du -sh /mnt/tmp/
24K /mnt/tmp/

24K, alors que le df montre 33M

-- 
jm

Re: augmenetation taille /tmp

[BERBAR Florian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/09/2015 18:41, Jean-Michel OLTRA wrote:
> 
> Bonjour,
> 
> 
> Le lundi 21 septembre 2015, BERBAR Florian a écrit...
> 
> 
>> Si un xfs_repair rend l'espace disque consommé, il est possible
>> que ton système de fichier soit corrompu. La partition ne
>> comprenant pas de données persistante un "reformatage" de ta
>> partition pourrait peut-être remettre les choses dans l'ordre.
> 
> Tous mes systèmes de fichiers seraient corrompus ? Sur tous les 
> volumes ? Je n'y crois pas trop. Mais je vais essayer, sur /tmp.
> Sur les autres, ce n'est pas possible.
> 
>> La sortie de l'utilitaire "xfs_repair" a t-elle donnée des 
>> informations ?
> 
> Pas vraiment. Pas d'erreur, en tous cas.

Pourrais-tu préciser les options que tu as passer à l'utilitaire
"xfs_repair" ? D'autre part, si cela n'as pas été le cas lors de ta
dernier utilisation de l'utilitaire "xfs_repair", pourrais-tu donner
la sortie de la commande en ajoutant l'option "-v" qui permet de
d'activer une sortie un peu plus bavarde ?

Toujours au sujet de ton système de fichier xfs, as tu tenté
d'examiner les volumes toucher par ton problème d'accroissement de
taille avec les utilitaire "xfs_io" ou "xfs_db" qui permet de déboguer
un système de fichier XFS.

Par exemple :

# xfs_db -c 'blockget -v -p' /dev/tondevice

Permet d'afficher des information sur les blocks et inodes traités.

Exécuter cette commande avant et après l'accroissement de taille
pourrait cibler les éventuelles les blocks et inodes impliquer.


La commande "xfs_io" quant à elle est permet d'auditer les
Entrées/Sorties de faites sur un système de fichier XFS.

Par exemple :

# xfs_io file

Permet d'afficher une liste des fichiers ouverts sur un système de
fichier donné.

# man xfs_db
ou
# man xfs_io

Pour plus d'informations.


Bon courage

Florian.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWAbRXAAoJEBGYNnE0a7qPS3gP/2hDm1zqL1d4E07rr3EmMIJp
HC9hICGNOuHaGwaLHLBONMYxlCGcJk9DrJAC6lHSoKpRMvwJKCB+BUd45tVnawHn
fzDA+xXLOQ2XeqbfZmbHyY5oCeq9M6aUm26FjoC0dA9EOVUojzkVUUMW8YgSE9Ie
XfPnEfy1A6gtcW2AU7pt8zE7D1S+db/Kbg5tWMezMfc/+5TjMoBoW6vfdPBqLZQg
Ez3U0EtLL/LxOHMYLnvLKCpGDcfm4H5JJq7OOVzYciOHt5UtkWWtMnKsSDo1FUn0
tCMGUYsEMZPUO3KlkCtXrZ/zcUaGU/AzJca8Ve4C122XP3+FErYAjkSAIbWlsJsE
CCKwrDimIhsbGayTgSoJGQ3QOscj2jJHf3Svfq91EW21VqeZb3k/dB6Q/ZpFo0g+
CJtDUpuU0bJ6+HYMajxKRU+dnnr70Nk38Zry3TTlyp7BcKzRNGJ2K2MYmmaKF7eR
akp4dW3EipmPThTaJ1Q+IidoPXWyonrgngOmcdvAbyYHxWI9nxbqWqMCH+BgSwab
97v1LByj31B0zEpkasmpXbLod22ERfBq2eE4SCQkV5WObTQUlF5zeSl+1hWlwVdv
3ERBiuVNrGb0cD3SauVo9Cj68iVCilriBMLDmD+0+/r3/YZUzcpYVX8r7ENvWmHV
jQeyTSLT3dEMuznvE5Pv
=qmRq
-END PGP SIGNATURE-

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le dimanche 20 septembre 2015, Jean-Michel OLTRA a écrit...


> Je me demande si ce n'est pas une partie du problème. Il y a de
> nombreuses années que j'utilise XFS, et c'est bien la première fois que
> ça me fait ce coup là (si c'est bien lié à xfs).

> Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux
> noyaux 4.x
> Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org

Problème partiellement résolu.

Un noyau en 4.0 ne change rien.

Un xfs_repair sur le volume rend l'espace disque consommé.

Mais au reboot, l'augmentation reprend, à coup de 32M.

Donc je sais comment revenir à la normale, mais je ne sais pas vraiment
ce qui pose problème, à part que ça semble lié à xfs, comme le
pressentait Pascal.

-- 
jm

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le lundi 21 septembre 2015, Jean-Michel OLTRA a écrit...


> Tous mes systèmes de fichiers seraient corrompus ? Sur tous les
> volumes ? Je n'y crois pas trop. Mais je vais essayer, sur /tmp. Sur les
> autres, ce n'est pas possible.

Pas mieux. +32M au reboot après formatage du VL monté sur /tmp

-- 
jm

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le lundi 21 septembre 2015, BERBAR Florian a écrit...


> Si un xfs_repair rend l'espace disque consommé, il est possible que
> ton système de fichier soit corrompu. La partition ne comprenant pas
> de données persistante un "reformatage" de ta partition pourrait
> peut-être remettre les choses dans l'ordre.

Tous mes systèmes de fichiers seraient corrompus ? Sur tous les
volumes ? Je n'y crois pas trop. Mais je vais essayer, sur /tmp. Sur les
autres, ce n'est pas possible.

> La sortie de l'utilitaire "xfs_repair" a t-elle donnée des
> informations ?

Pas vraiment. Pas d'erreur, en tous cas.


-- 
jm

Re: augmenetation taille /tmp

[BERBAR Florian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/09/2015 13:48, Jean-Michel OLTRA wrote:
> Un xfs_repair sur le volume rend l'espace disque consommé.

Si un xfs_repair rend l'espace disque consommé, il est possible que
ton système de fichier soit corrompu. La partition ne comprenant pas
de données persistante un "reformatage" de ta partition pourrait
peut-être remettre les choses dans l'ordre.

> Mais au reboot, l'augmentation reprend, à coup de 32M.

La sortie de l'utilitaire "xfs_repair" a t-elle donnée des informations
?

Bon courage,

Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWAA6OAAoJEBGYNnE0a7qPdsgQAJAHypBZg8Ccp4wwpQWRMNwT
eV28R2Sl8W3CDEPWAU/tRcXyUhM4FM63nfWe6w0lhG83zxzOk6cTiornUGryJjsk
NqcFLw+g5DsjDwCiudYvpWhKbInQt1SttEgpql81fRaigU7+7Gvbo0IIIbri9+Ya
diba87NGnuLsh0xaZpGTp1lvtFfjW7DVSQoiiaAhCvjCTm9BP2QTOizvmxetybVx
po1Eap4N9W4VvVkznbZ+kr9PObDKRR3eE914Nf28LBd3didJc+/FWDfp3vNuQ4cp
SdPqBz46z68Xk1tHDv9xXUm7u6z9E4A2bA3Q/H8HeIs9zFBkbsUcoCV+B3OpcNyU
1nJ7SZygyeWEyeGquh/Z4rGi/ZuxrExN8LXpxtdZUZtNf3HDYfwqSoA4HuVxqBcG
QxQrTolwXVeUOGjLBT32GGv1Pq5hAxzsg6ujG3tnbj7KoMlfBXAo56JsJXU3JszH
v+3n+Tu4B/XIvAR3DZ3gk9ulNktaD/U1jI9VWpWFDcAgc0l5F60K0z4mql7e2Hy0
bgYV6/LR5FP4hKBb1k8YCxGpVMWAOIf1dy4V05QCXG3Xvu5c4ulVlt6jXK0BsO+0
Q5bBrYZaNqqQ0QLBlUkqzl/jgb4n7xHldkz1h/FedvNKnKHLFB9T3LVTiWRTXH2b
kq1y7BjHuohoL2714I0N
=QWOT
-END PGP SIGNATURE-

Re: augmenetation taille /tmp

[Philippe Gras]

Le 20 sept. 2015 à 00:46, Francois Lafont  a écrit :

> On 19/09/2015 23:40, Jean-Michel OLTRA wrote:
> 
>>> Personnellement, je ne comprends pas qu'un reboot n'ait pas résolu
>>> ce problème.
>> 
>> 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 !
> 
> 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.

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 ?

> 
> 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
> 

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le dimanche 20 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 !

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…

> 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.

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  1598mysql5u   REG  253,10  135 /tmp/ibQZHR5l (deleted)
mysqld  1598mysql6u   REG  253,1  101  136 /tmp/ibaQ1rC0 (deleted)
mysqld  1598mysql7u   REG  253,10  137 /tmp/ibIoH28E (deleted)
mysqld  1598mysql8u   REG  253,10  138 /tmp/ibuX4pgY (deleted)
mysqld  1598mysql   12u   REG  253,10  139 /tmp/ibT8zJyG (deleted)
apache2 1712 root   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
(deleted)
apache2 6504 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
(deleted)
apache2 6505 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
(deleted)
apache2 6506 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
(deleted)
apache2 6507 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
(deleted)
apache2 6508 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
(deleted)

> 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 ? ;)

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 root6 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 root6 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 root6 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 root6 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

Re: augmenetation taille /tmp

[Sylvain L. Sauvage]

Le dimanche 20 septembre 2015, 11:02:26 Sylvain L. Sauvage a 
écrit :
> Le dimanche 20 septembre 2015, 10:44:17 Jean-Michel OLTRA a
> 
> écrit :
> > Bonjour,
> 
> ’jour,
> 
> >[…]
> >
> > 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.
>   Et des snapshots LVW au boot ?
>   Bon, il faudrait que la taille d’un instantané « vide » soit
> de 32 Mo pour le /home/laurena, et ça me paraît beaucoup…

Remarque, il n’est peut-être pas vide s’il est aussi monté avec 
relatime et qu’une lecture complète est faite (locate ou autre).

-- 
 Sylvain Sauvage

Re: augmenetation taille /tmp

[Sylvain L. Sauvage]

Le dimanche 20 septembre 2015, 10:44:17 Jean-Michel OLTRA a 
écrit :
> Bonjour,

’jour,

>[…]
> 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.

  Et des snapshots LVW au boot ?
  Bon, il faudrait que la taille d’un instantané « vide » soit 
de 32 Mo pour le /home/laurena, et ça me paraît beaucoup…

-- 
 Sylvain Sauvage

Re: augmenetation taille /tmp

[Pascal Hambourg]

Jean-Michel OLTRA a écrit :
> 
>>   Et quel est le FS ?
> 
> 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.

Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors
des volumes logiques et leurs systèmes de fichiers.

Je soupçonne plutôt le système de fichiers lui-même. Peut-être un
journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...

Tu peux démarrer un autre système (live par exemple) dont tu es sûr
qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace
occupé affiché par du et df coïncide.

Re: augmenetation taille /tmp

[Fabien R]

On 19/09/2015 23:16, Jean-Michel OLTRA wrote:
> 
> 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.
> 
> 
Tu peux afficher les sorties de df ?

--
Fabien

Re: augmenetation taille /tmp

[Francois Lafont]

On 20/09/2015 10:44, Jean-Michel OLTRA wrote:

> espinasse:~$ lsof /tmp

J'avais indiqué la commande « lsof | grep /tmp », pas la commande
ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué,
il faut mieux lancer la commande en tant que root.

> COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> mysqld  1598mysql5u   REG  253,10  135 /tmp/ibQZHR5l (deleted)
> mysqld  1598mysql6u   REG  253,1  101  136 /tmp/ibaQ1rC0 (deleted)
> mysqld  1598mysql7u   REG  253,10  137 /tmp/ibIoH28E (deleted)
> mysqld  1598mysql8u   REG  253,10  138 /tmp/ibuX4pgY (deleted)
> mysqld  1598mysql   12u   REG  253,10  139 /tmp/ibT8zJyG (deleted)
> apache2 1712 root   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
> (deleted)
> apache2 6504 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
> (deleted)
> apache2 6505 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
> (deleted)
> apache2 6506 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
> (deleted)
> apache2 6507 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
> (deleted)
> apache2 6508 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
> (deleted)

Je suis très surpris que la commande « lsof /tmp » que tu as tapée
t'indique des fichiers « deleted » dans /tmp vu que normalement la
commande va faire une recherche dans les fichiers qui se trouvent
dans l'arborescence de /tmp et donc des fichiers forcément non deleted.
Du coup ta commande me semble incohérente. Ceci étant, on voit des
fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.

-- 
François Lafont

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le dimanche 20 septembre 2015, Pascal Hambourg a écrit...


> Je ne vois pas comment. Les méta-données de LVM sont stockées en dehors
> des volumes logiques et leurs systèmes de fichiers.

Oui, j'ai vu ça.

> Je soupçonne plutôt le système de fichiers lui-même. Peut-être un
> journal qui grossit, un snapshot qui s'ajoute, (si ça existe sur XFS)...

Possible. Je vais voir si je peux évaluer l'évolution de la taille des
logs du fs.

> Tu peux démarrer un autre système (live par exemple) dont tu es sûr
> qu'il n'écrit rien sur ces volumes, et tu pourras voir si l'espace
> occupé affiché par du et df coïncide.

Bonne idée. Je ferai la manip au prochain reboot (demain).

J'ai désactivé le montage au boot d'un des volumes. Je verrai si ça
induit un changement.

Merci.

Au fait : personne en LVM et XFS sur la liste…?

-- 
jm

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le dimanche 20 septembre 2015, Daniel Huhardeaux a écrit...


> >Au fait : personne en LVM et XFS sur la liste…?

> Si, sur plusieurs serveurs en wheezy et jessie, rien noté de spécial.

Je me demande si ce n'est pas une partie du problème. Il y a de
nombreuses années que j'utilise XFS, et c'est bien la première fois que
ça me fait ce coup là (si c'est bien lié à xfs).

Il se pourrait que mes soucis aient débuté avec l'arrivée des nouveaux
noyaux 4.x
Je vais voir à installer un noyau 4.0 de chez snapshot.debian.org


-- 
jm

Re: augmenetation taille /tmp

[Daniel Huhardeaux]

Le 20/09/2015 18:38, Jean-Michel OLTRA a écrit :

[...]
Au fait : personne en LVM et XFS sur la liste…? 


Si, sur plusieurs serveurs en wheezy et jessie, rien noté de spécial.

--
Daniel

Re: augmenetation taille /tmp

[Sylvain L. Sauvage]

Le dimanche 20 septembre 2015, 18:47:50 Francois Lafont a écrit 
:
> On 20/09/2015 10:44, Jean-Michel OLTRA wrote:
> > espinasse:~$ lsof /tmp
> 
> J'avais indiqué la commande « lsof | grep /tmp », pas la
> commande ci-dessus.

  Le résultat est le même quand /tmp est un point de montage, ce 
qui est le cas ici.

-- 
 Sylvain Sauvage

Re: augmenetation taille /tmp

[Erwan David]

Le 20/09/2015 18:47, Francois Lafont a écrit :
> On 20/09/2015 10:44, Jean-Michel OLTRA wrote:
>
>> espinasse:~$ lsof /tmp
> J'avais indiqué la commande « lsof | grep /tmp », pas la commande
> ci-dessus. Par ailleurs, et là par contre je ne l'ai pas indiqué,
> il faut mieux lancer la commande en tant que root.
>
>> COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>> mysqld  1598mysql5u   REG  253,10  135 /tmp/ibQZHR5l 
>> (deleted)
>> mysqld  1598mysql6u   REG  253,1  101  136 /tmp/ibaQ1rC0 
>> (deleted)
>> mysqld  1598mysql7u   REG  253,10  137 /tmp/ibIoH28E 
>> (deleted)
>> mysqld  1598mysql8u   REG  253,10  138 /tmp/ibuX4pgY 
>> (deleted)
>> mysqld  1598mysql   12u   REG  253,10  139 /tmp/ibT8zJyG 
>> (deleted)
>> apache2 1712 root   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
>> (deleted)
>> apache2 6504 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
>> (deleted)
>> apache2 6505 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
>> (deleted)
>> apache2 6506 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
>> (deleted)
>> apache2 6507 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
>> (deleted)
>> apache2 6508 www-data   10u   REG  253,10  132 /tmp/.ZendSem.AEtmFA 
>> (deleted)
> Je suis très surpris que la commande « lsof /tmp » que tu as tapée
> t'indique des fichiers « deleted » dans /tmp vu que normalement la
> commande va faire une recherche dans les fichiers qui se trouvent
> dans l'arborescence de /tmp et donc des fichiers forcément non deleted.
> Du coup ta commande me semble incohérente. Ceci étant, on voit des
> fichiers deleted encore utilisés dans /tmp mais ils ne sont pas bien gros.
>
C'est au contraire tout à fait normal : lsof va regarder dans le kernel
les fichiers ouverts. Un fichier peut avoir été ouvert puis avoir été
supprimé, tant qu'il est ouvert il sera sur le disque mais pas
accessible. C'est très courant sur les fichiers temporaires qui n'ont
pas besoin de survivre à l'instance du programme de créer le fichier
puis immédiatement le supprimer. Ainsi on est sûr qu'il ne trainera pas
sur le disque quelle que soit la raison de la fermeture du programme.

Re: augmenetation taille /tmp

[Francois Lafont]

On 19/09/2015 23:40, Jean-Michel OLTRA wrote:

>> Personnellement, je ne comprends pas qu'un reboot n'ait pas résolu
>> ce problème.
> 
> 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 !

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

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le samedi 19 septembre 2015, Francois Lafont a écrit...


> Personnellement, je ne comprends pas qu'un reboot n'ait pas résolu
> ce problème.

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

Re: augmenetation taille /tmp

[Jean-Michel OLTRA]

Bonjour,


Le samedi 19 septembre 2015, Sylvain L. Sauvage a écrit...


> > L'occupation de ma partition montée sur /tmp augmente
> > régulièrement. C'est un volume logique.

>   Qu’est ce que tu entends par « volume logique » ? Un LV de LVM ?  Tu
>   penses que ça peut être un facteur ?

C'est bien un LV de LVM.
Et je commence à me dire que c'est peut-être un facteur.

>   Autrement dit, la partition se remplit mais aucun fichier 
> n’apparaît prendre cet espace.

Oui.

>   Donc les fichiers en cours mais effacés ne semblent pas être 
> ceux qui prennent de l’espace.

Oui.

>   Et arrêter les suspects habituels ne libère pas l’espace 
> disque qui, je suppose, n’est toujours pas rendu et n’est 
> toujours dans aucun répertoire…?

Exact, ça ne change rien. Certains fichiers marqués comme (deleted)
disparaissent (apache, mysqld). Mais ça n'apporte rien.

> > Une idée pour un meilleur diagnostic ?

>   Je suppose que tu as vérifié que l’espace utilisé grossit 
> toujours même sans les services ?

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).

>   Et si tu réduits la taille de la partition et que tu attends que
>   quelqu’un plante ?

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.

>   Et quel est le FS ?

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

Re: augmenetation taille /tmp

[Francois Lafont]

Bonjour,

On 19/09/2015 19:22, Sylvain L. Sauvage wrote:

>> 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.
> 
>   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 :

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

augmenetation taille /tmp

[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

Re: augmenetation taille /tmp

[Sylvain L. Sauvage]

Le samedi 19 septembre 2015, 10:39:36 Jean-Michel OLTRA a écrit 
:
> Bonjour,

’soir,

> L'occupation de ma partition montée sur /tmp augmente
> régulièrement. C'est un volume logique.

  Qu’est ce que tu entends par « volume logique » ? Un LV de 
LVM ?
  Tu penses que ça peut être un facteur ?

  Bon, à partir d’ici, je vais reformuler pour vérifier que l’on 
comprend bien…

> 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.

  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 :

> 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.

  Donc les fichiers en cours mais effacés ne semblent pas être 
ceux qui prennent de l’espace.

> 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.

  Et arrêter les suspects habituels ne libère pas l’espace 
disque qui, je suppose, n’est toujours pas rendu et n’est 
toujours dans aucun répertoire…?

> Une idée pour un meilleur diagnostic ?

  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