[RESOLU] Partition / à 100% sans raison (pour le moment)

Support Debian
#1

Bonjour à tous et à toutes,

J’ai un souci à l’heure actuelle sur l’un de mes serveurs. Si vous avez des idées je suis preneur.

Depuis quelques temps, ma partition / est à 100% et je n’arrive pas à savoir pourquoi. En temps normal, elle est très peu utilisée, à peine 400Mo.

Machine : Debian Etch 2.6.18-6-686 #1 SMP
Socle : Serveur ESX sur un SAN EMC => Il s’agit donc d’une machine virtualisée.
RAM : 2Go

server:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 1.9G 1.9G 0 100% / tmpfs 1015M 0 1015M 0% /lib/init/rw udev 10M 76K 10M 1% /dev tmpfs 1015M 0 1015M 0% /dev/shm /dev/sdb5 227G 187G 28G 87% /data /dev/sda5 942M 18M 877M 2% /tmp /dev/sda3 3.7G 908M 2.6G 26% /usr /dev/sda6 8.5G 1.1G 7.0G 14% /var

J’ai rebooté la machine plusieurs fois pour voir s’il y avait une histoire de cache et rien n’y fait.
J’ai regardé les fichiers qui prenaient le plus de place et à part le fichier /proc/kcore (1Go environ) il n’y a rien d’autre. Par ailleurs, il s’agit d’un fichier virtuel donc aucun souci.

Au niveau des processus, j’ai un apache2, un svn, et un tomcat (outil nexus). Le process Java prend pas mal de place, mais seulement au niveau CPU.

Sur la partition /, il n’y a pas de compte utilisateur dans /home, seulement la configuration des machines, tous les outils sont installés sur le /data.

J’ai également effectué un e2fsck et un fsck.ext3 sur /dev/sda1 afin de voir si le filesystem était touché et on dirait que non.

Si vous avez des pistes, je suis preneur, là je patauge pas mal.

Merci
Bonne journée,
MEtaltux

#2

La commande du -shx /* te donnera la taille de chaque répertoire en dessous de la racine.
En ne tenant pas compte des partitions montées ailleurs, tu trouveras peut-être les fichiers et/ou dossiers qui prennent de la place.

Tu peux également utiliser des commandes comme find / -size +100M pour trouver les gros fichiers.

#3

J’ai eu une fois un problème similaire et j’ai fini par trouver.

J’avais des fichiers log énormes. Pour chacun des fichiers log je les ai remplacé par un fichier vide.
C’était du à un bug d’un des paquets de sid. Depuis ce problème j’ai une sid et une testing avec un même home.

#4

Hum, les fichiers log sont dans /var qui est une partition à part.

  1. Je ne vois pas de partition /home, donc le /home est sur ta racine, as tu un utilisateur gourmand?

  2. Vérifie le répertoire /tmp

#5

Merci

Je n’ai aucun utilisateur, les logs sont dans une partition à part et le /tmp est également dans une partition à part.

srv-vid-tux1:~# du -shx /*
3.9M    /bin
18M     /boot
0       /cdrom
112K    /dev
8.2M    /etc
4.0K    /home
4.0K    /initrd
0       /initrd.img
0       /initrd.img.old
102M    /lib
16K     /lost+found
12K     /media
12K     /mnt
98M     /opt
[b]910M    /proc[/b]
96K     /root
2.8M    /sbin
4.0K    /srv
0       /sys
36K     /tmp
0       /vmlinuz
0       /vmlinuz.old

il n’y a donc que le fichier /proc/kcore qui est énorme.

#6

/proc/kcore est un accès direct à la mémoire vive, donc il est de la taille de ta mémoire et ne prend rien comme place disque. (Tu n’as qu’à faire un umount /proc si tu veux en être convaincu)

Je pense donc à un fichier supprimé mais encore ouvert dans /tmp ou ailleurs.
Que donne un

lsof

#7

le lsof est un peu long à mettre ici, je l’ai mis en pièce jointe sur le forum.

merci
lsof.tar.bz2 (15 KB)

#8

Nous venons de checker également le FS du serveur ESX et il n’y a rien qui cloche.

Étonnant mystère.

#9

.

#10

[quote=“Metaltux”]le lsof est un peu long à mettre ici, je l’ai mis en pièce jointe sur le forum.

merci[/quote]
Tu as un paquet de fichiers ouverts et détruits sous /data/sonatype-work/nexus/indexer/apache-incubator-releases-local/ , /data/sonatype-work/nexus/indexer/java-net-2-releases-local/ , /data/sonatype-work/nexus/indexer/vidal-merged/ etc

Bref, c’est surement ça, ces fichiers doivent être gros. [edit: je confirme, ils sont gros!, il y en a pour 590M au total au moins]

C’est un java qui tourne. Tue ce processus (pid 2105) et relance le, ça te libérera ta mémoire. Il y a un souci sur ce processus, il détruit des fichiers sans les fermer…

#11

Merci

Cependant, j’ai déjà tenté de relancer ce service et rien n’y fait.
Par ailleurs, ces fichiers sont sur /data/ donc pas en cause dans le soucis.

#12

Oups, j’avais pourtant vérifié que ça ne correspondait pas à une partition séparée, mal lu on dirait, dsl. As tu fait un fsck de la partition racine? Du coup je ne vois que ça… Tu montes la partition racine après un boute sur CD live et tu vérifies que c’est toujours à 100%, si oui, un fsck te réparera le truc, sinon, la seule chose que je verrais (mais ça serait surprenant) est un fichier temporaire (sous /tmp) ouvert avant que la partition ne soit montée, le fichier continue à remplir le disque (toujours présent) mais est invisible car caché par la partition montée sur /tmp. De même pour /var. En clair je vérifierais avec soin le contenu de /var et de /tmp dans ta partition sous un CD-Live, je suis sur qu’il y a quelque chose dedans…

#13

je vais restester ce soir je pense, comme il s’agit d’une machine en production je ne peux pas l’arrêter dans la journée.

J’avais déjà effectuer un fsck et un e2fsck sur le / et il n’y avait rien de suspect.
Cependant, il faudrait que je le fasses sur les autres partitions pour voir si le problème ne viendrait pas de là.

Ce problème m’ennuie pas mal ;-(

merci en tout cas pour votre aide.

#14

Une bonne idée peut être de regarder si des services sont lancés avant le montage des partitions. Cependant celui ci a lieu très tôt…

Sinon que donne un

tune2fs -l /dev/sda1

#15 
server:~# tune2fs -l /dev/sda1
tune2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          ad5d835c-700f-4ffd-b409-0f9ce6ff0711
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_reco                                                                              very sparse_super large_file
Filesystem flags:         signed directory hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              244320
Block count:              487966
Reserved block count:     24398
Free blocks:              2
Free inodes:              231613
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      119
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16288
Inode blocks per group:   509
Filesystem created:       Mon Feb 25 16:02:11 2008
Last mount time:          Mon Oct 27 23:09:49 2008
Last write time:          Mon Oct 27 23:09:49 2008
Mount count:              1
Maximum mount count:      37
Last checked:             Mon Oct 27 23:04:18 2008
Check interval:           15552000 (6 months)
Next check after:         Sun Apr 26 00:04:18 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      27a98e75-991e-4271-a255-b8517de35e7e
Journal backup:           inode blocks
#16

Et en utilisant debugfs?
(par défaut il est en lecture seule)

debugfs /dev/sda1

ffb

ffi

lsdel

#17 
server:~# debugfs /dev/sda1
debugfs 1.40-WIP (14-Nov-2006)
debugfs:  ffb
Free blocks found: 352256
debugfs:  ffi
Free inode found: 17
debugfs:  lsdel

lsdel n’a révélé : aucun inode deleted

#18

server:~# e2fsck /dev/sda1
e2fsck 1.40-WIP (14-Nov-2006)
/dev/sda1: clean, 12708/244320 files, 487962/487966 blocks

#19

bon là je sèche.

J’ai créé un fichier /forcefsck afin de faire un fsck sur toutes les partitions et rien à faire. Je suis toujours à 100% sur le /.

J’ai désactivé également les montages réseaux au démarrage au cas où, cela ne fait rien.

Je vais désactiver le lancement du java au reboot de la machine pour voir si le problème ne viendrait pas que de là.

#20

As tu regardé la présence de fichier sous /tmp, tu dois pouvoir le faire sous debugfs y compris sur un système monté. Il y a un gros fichier que tu ne vois pas, ce fichier peut être caché ou sous un répertoire sur lequel tu montes une partition. debugfs te permettra de le trouver: (fais un ls -l sous debugfs tout bêtement…)