Partition racine plein [resolu]

Support Debian
#1

Bonjour à tous

Je reviens vers vous pour ma partition racine qui est pleine et qui, malgré mes efforts, ne veux pas ce libérer.

J’ai effectué les procédure de nettoyage classique (localepuge, apt-get clean autoclean, deborphan…) sans résultats

Je ne comprends pas. /temp /usr et /var sont montés sur des partitions différentes. Si je fait la somme des répertoires (bin boot dev etc lib opt root sbin proc boot …) j’arrive à moins de 500 mo!

La distribution est une debian squeeze avec le noyaux 2.6.32-5-amd64

df -h

[code]

root@damdam:/home/utilisateur# df -h
Sys. de fichiers Taille Uti. Disp. Uti% Monté sur
/dev/sdb1 2,8G 2,8G 0 100% /
tmpfs 1002M 0 1002M 0% /lib/init/rw
udev 997M 220K 997M 1% /dev
tmpfs 1002M 156K 1002M 1% /dev/shm
/dev/sdb9 445G 160G 263G 38% /home
/dev/sdb8 919M 18M 855M 2% /tmp
/dev/sdb5 4,8G 2,8G 1,9G 61% /usr
/dev/sdb6 3,1G 620M 2,4G 21% /var
/dev/sda1 1,8T 1,5T 356G 81% /media/stockage-r[/code]

du -sh /*

root@damdam:/home/utilisateur# du -sh /* 5,9M /bin 18M /boot 376K /dev 11M /etc 1,8T /home 0 /initrd.img.old 116M /lib 0 /lib64 16K /lost+found du: impossible de lire le répertoire « /media/mediacenter/mediacenter »: Aucun fichier ou dossier de ce type 1,5T /media 4,0K /mnt 248M /opt du: impossible d'accéder à « /proc/2920/task/2920/fd/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/2920/task/2920/fdinfo/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/2920/fd/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/2920/fdinfo/4 »: Aucun fichier ou dossier de ce type 0 /proc 888K /root 5,6M /sbin 4,0K /selinux 4,0K /srv 0 /sys 64K /tmp 2,6G /usr 551M /var 0 /vmlinuz.old

Si quelqu’un à une idée…

#2

Par exemples:

Une aperçue global

Un soupçon ?

Besoin de peaufiner ?

Un coupable présumé ?

Ainsi de suite …

#3

J’ai eu ce problème il y a quelques temps, regarde le /var/log

#4
#5

Quels sont les derniers “rm” en date ?
Lorsque du et df divergent, bien souvent la cause en est la suppression de fichiers qui persistent dans les processus en cours. Surveiller les processus lancés : ps, top, lsof, /proc …

Interrompre les processus en prise avec les fichier supprimés devrait faire apparaître l’espace libre.

#6

[quote=“etxeberrizahar”]
Interrompre les processus en prise avec les fichier supprimés devrait faire apparaître l’espace libre.[/quote]

Exact!

Recherches ce qui plombe l’espace disque …

relances à nouveau un lsof, ainsi de suite …

Nota: ne pas oublié de relancer le(s) dit service, après.

#7

Si tu n’as pas besoin d’infos sur ton ordi, tu peux supprimer le contenu de /var/log sans souci. Mais vu qu’il prend 21%, c’est certainement un fichier de log qui se remplit trop vite comme le dit M3t4linux

#8

Place-toi dans la racine de la partition /dev/sdb1, puis fait un ls -lh / pour voir.

#9

Bonjour,

[quote=“damdam”]

Je ne comprends pas. /temp /usr et /var sont montés sur des partitions différentes.


root@damdam:/home/utilisateur# df -h
Sys. de fichiers    Taille  Uti. Disp. Uti% Monté sur
/dev/sdb1             2,8G  2,8G     0 100% /

[/quote][/quote]

Sinon, il y a aussi la possibilité d’une écriture sur un point de montage alors que la partition est démontée.

#10

Beaucoup de réponse en peux de temps…

Alors.

La répertoire var est monté sur un partition différente de la racine donc il n’est pas en cause.

du -h --max-depth=1 / | sort -rh

root@damdam:/home/utilisateur# du -h --max-depth=1 / | sort -rh du: impossible d'accéder à « /proc/3753/task/3753/fd/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/3753/task/3753/fdinfo/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/3753/fd/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /proc/3753/fdinfo/4 »: Aucun fichier ou dossier de ce type du: impossible d'accéder à « /media/mediacenter/mediacenter »: Aucun fichier ou dossier de ce type 3,3T / 1,8T /home 1,5T /media 2,6G /usr 551M /var 248M /opt 116M /lib 18M /boot 11M /etc 5,9M /bin 5,6M /sbin 888K /root 376K /dev 76K /tmp 16K /lost+found 8,0K /.ure 4,0K /srv 4,0K /selinux 4,0K /mnt 0 /sys 0 /proc

Je ne remarque rien à part le répertoire /proc/3753 qui est inaccessible

lsof | grep deleted

root@damdam:/home/utilisateur# lsof | grep deleted apache2 1399 root 11w REG 8,22 0 1048 /var/run/apache2/ssl_mutex (deleted) apache2 1596 utilisateur 11w REG 8,22 0 1048 /var/run/apache2/ssl_mutex (deleted) apache2 1598 utilisateur 11w REG 8,22 0 1048 /var/run/apache2/ssl_mutex (deleted) apache2 1599 utilisateur 11w REG 8,22 0 1048 /var/run/apache2/ssl_mutex (deleted) apache2 1600 utilisateur 11w REG 8,22 0 1048 /var/run/apache2/ssl_mutex (deleted) apache2 1604 utilisateur 11w REG 8,22 0 1048 /var/run/apache2/ssl_mutex (deleted) nautilus 1999 utilisateur 19r REG 8,25 35588 2885102 /home/utilisateur/.local/share/gvfs-metadata/home (deleted) nautilus 1999 utilisateur 20w REG 8,25 32768 2896634 /home/utilisateur/.local/share/gvfs-metadata/home-d0ccaf19.log (deleted) gnome-ter 2751 utilisateur 21u REG 8,24 23976 51 /tmp/vteLPN6SW (deleted) gnome-ter 2751 utilisateur 22u REG 8,24 5680 52 /tmp/vteGKN6SW (deleted) gnome-ter 2751 utilisateur 23u REG 8,24 768 54 /tmp/vteCS2RSW (deleted) gnome-ter 2751 utilisateur 25u REG 8,24 26316 57 /tmp/vteSHHSSW (deleted) gnome-ter 2751 utilisateur 26u REG 8,24 8192 59 /tmp/vteW2HSSW (deleted) gnome-ter 2751 utilisateur 27u REG 8,24 19771 60 /tmp/vte1M4QSW (deleted) gnome-ter 2751 utilisateur 28u REG 8,24 5472 61 /tmp/vteYE4QSW (deleted) apache2 3642 utilisateur 11w REG 8,22 0 1048 /var/run/apache2/ssl_mutex (deleted)

Je ne comprends pas cette commande. Nautilus semble prendre beaucoup de place mais c’est dans le home.

ls -lh /root@damdam:/# ls -lh / total 100K drwxr-xr-x 2 root root 4,0K 15 nov. 19:31 bin drwxr-xr-x 3 root root 4,0K 15 nov. 20:04 boot drwxr-xr-x 15 root root 3,2K 22 févr. 10:11 dev drwxr-xr-x 143 root root 12K 22 févr. 10:11 etc drwxr-xr-x 7 root root 4,0K 13 juil. 2011 home lrwxrwxrwx 1 root root 30 27 mai 2011 initrd.img.old -> boot/initrd.img-2.6.32-5-amd64 drwxr-xr-x 13 root root 12K 18 févr. 09:34 lib lrwxrwxrwx 1 root root 4 12 avril 2011 lib64 -> /lib drwx------ 2 root root 16K 12 avril 2011 lost+found drwxr-xr-x 10 root root 4,0K 2 févr. 17:39 media drwxr-xr-x 2 root root 4,0K 12 mars 2011 mnt drwxr-xr-x 3 root root 4,0K 17 juil. 2011 opt dr-xr-xr-x 251 root root 0 22 févr. 10:10 proc drwx------ 18 root root 4,0K 22 févr. 10:21 root drwxr-xr-x 2 root root 4,0K 15 nov. 19:31 sbin drwxr-xr-x 2 root root 4,0K 21 juil. 2010 selinux drwxr-xr-x 2 root root 4,0K 12 avril 2011 srv drwxr-xr-x 13 root root 0 22 févr. 10:10 sys drwxrwxrwt 13 root root 12K 22 févr. 13:39 tmp drwxr-xr-x 11 root root 4,0K 18 févr. 09:34 usr drwxr-xr-x 16 root root 4,0K 18 févr. 09:43 var lrwxrwxrwx 1 root root 27 27 mai 2011 vmlinuz.old -> boot/vmlinuz-2.6.32-5-amd64

#11

C’est une piste…
J’ai effectivement un sauvegarde automatique qui ce fait 2 fois par semaine
/etc/crontab appelle le fichier sauvegarde.sh
sauvegarde.sh

#!/bin/bash mount /media/stockage-r2 rsync -urgo --delete /media/stockage-r/ /media/stockage-r2/ umount /media/stockage-r2 apt-get update

Mon disque dur /media/stockage-r2/ était déconnecté. Je l’ai reconnecté et effectué une nouvelle sauvegarde.

J’ai récupèré 360Mo sur ma racine.

Des fichiers sont toujours présent dans le repertoire /media/stockage-r2
Il sont en lecture seul et je n’arrive pas à les supprimer
j’ai toujours le message suivant “Système de fichiers accessible en lecture seulement”

#12

[quote=“damdam”]
du -sh /*

root@damdam:/home/utilisateur# du -sh /* ... 2,6G /usr 551M /var ...

/usr et /var semblent volumineux :079

fait :

root@damdam:/home/utilisateur# du -sh /usr/*;du -sh /var/*
#13

Si tu regarde son premier message, ces deux répertoires sont montés sur des partitions différentes de la racine.

Sinon as tu utilisé un outil tel Baobab ? Pratique pour visualisé rapidement ce qui prend toute la place.

#14

Peux tu poster:
fstab
fdisk -l
du -am /* | sort -n (ca tu le fou dans un pastebin ou un fichier)
ls -l /media/

#15

Tu as à présent /usr et /var sur des partitions séparées, cependant les dossiers correspondants ne sont peut-être pas vides sur /dev/sdb1 (si tu n’as pas utilisé ces partitions dès le début de la vie de ton OS) ?
Si tu arrives à démonter ces partitions (démarrage en mode “maintenance”) tu pourrais vérifier que ces dossiers sont bien vides.

#16

[quote=“sebB”]Peux tu poster:
fstab
fdisk -l
du -am /* | sort -n (ca tu le fou dans un pastebin ou un fichier)
ls -l /media/[/quote]+1 et la sortie de “mount” aussi.

[quote=“damdam”]#!/bin/bash mount /media/stockage-r2 rsync -urgo --delete /media/stockage-r/ /media/stockage-r2/ umount /media/stockage-r2 apt-get update[/quote]
C’est pas bien un script sur un répertoire monté sans vérification du montage préalable (surtout s’il s’agit d’un disque amovible…).
Il suffit de vérifier le montage avant de lancer quoi que ce soit comme commande.
S’il n’existe pas, tentative de montage, si le montage échoue mail à root.

#17

J’ai démarré le PC avec une distribution live et j’ai vérifié tous les points de montage. Le point /media/stockager2 n’était pas vide et j’ai pu effacer les fichiers via la distribution live.

Merci à tous de votre aide

Lol: As tu une ligne de commande à insérer dans mon script pour vérifier le montage?

#18

Salut,

Plusieurs possibilités:

if mount | grep /media/stockage-r2 > /dev/null; then echo "Monté" else echo "non monté" fi

Ou quelque chose dans ce style:

#19

Merci beaucoup de ta réponse.