Debian 8 - Problème d'espace disque /dev/root/

Salut tout le monde,
J’ai un soucis j’ai ma partition / qui est a 82% :
# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root 20G 15G 3,4G 82% /
devtmpfs 63G 0 63G 0% /dev
tmpfs 63G 0 63G 0% /dev/shm
tmpfs 63G 2,1G 61G 4% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 63G 0 63G 0% /sys/fs/cgroup
/dev/md3 1,8T 251G 1,5T 15% /home
ftpbackup:/export/ftpbackup/ 1000G 703G 298G 71% /mnt/FTPBackup

Mais impossible de savoir d’ou ça provient:
8,9M bin
22M boot
0 dev
18M etc
40M lib
4,0K lib64
16K lost+found
8,0K media
4,4G /var
1,4G /usr
12K /srv
23M /sbin
17M /root
4,0K /opt

Vous avez pas une idée !!!

20Go pour ta partition racine, là ou s’installent les logiciels et ou sont stockés les logs qui grossissent jour aprés jour, c’est plutôt petit.

Tu peux regarder dans /var/log pourquoi tes logs archivés prennent à eux seuls 4Go, supprimer les logs les plus anciens, et essayer de diminuer les traces de logs pour que les fichiers ne regrossissent pas trop.

Pour te rassurer, il reste quand même 3.4Go sur ton disque: il y a encore large de la place pour installer des softs, et si tes logs prennent actuellement 4Go, imagine le temps qu’il faudra pour qu’ils produisent encore 3Go de plus.

Cherchez de ce côté là. En particulier le cache de apt dans /var/cache/apt/archives/ et les journaux dans /var/log
Vérifiez que logrorotate est installé.

Un seul noyau ?

fp2@debpacha:~$ df -hT /  /var /boot
Sys. de fichiers             Type Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/pacha_vg-root_lv ext4   7,9G    4,9G  2,5G  67% /
/dev/mapper/pacha_vg-var_lv  xfs    4,0G    1,5G  2,6G  36% /var
/dev/sda1                    ext4   2,0G     94M  1,7G   6% /boot
fp2@debpacha:~$ 

Donnez le retour de

df -hTx tmpfs

en utilisant le formatage de bloc de texte à base de 3 backticks

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer. »
Antoine de Saint-Exupéry

salut
d’accord avec tout ce qui est au dessus
voir aussi /var/www/html si tu as un serveur apache
regarder aussi avec
du -sh /var/*
remarque : chez moi / est à 50G ( mais j’utilise /var/www/html et /opt )

salut
une première commande pour lister avec critère de taille 1G

du -sht 1G /* 2>/dev/null | sort -h

Exemple
root@debian:~# du -sht 1G /* 2>/dev/null | sort -h
1,5G /var
1,7G /opt
3,0G /Phoenix
6,3G /usr
213G /home
root@debian:~#

Puis descendre l’arborescence,

du -hxd1 /var/* 2>/dev/null | sort -h

Exemple

root@debian:~# du -hxd1 /var/* 2>/dev/null | sort -h
0 /var/lock
0 /var/run
4,0K /var/cache/private
4,0K /var/cache/realmd
4,0K /var/lib/apache2
4,0K /var/lib/avahi-autoipd
4,0K /var/lib/blueman
4,0K /var/lib/container
4,0K /var/lib/dhcp
4,0K /var/lib/git
4,0K /var/lib/ieee-data
4,0K /var/lib/initscripts
4,0K /var/lib/insserv
4,0K /var/lib/lsb
4,0K /var/lib/man-db
4,0K /var/lib/minidlna
4,0K /var/lib/misc
4,0K /var/lib/os-prober
4,0K /var/lib/python
4,0K /var/lib/realmd
4,0K /var/lib/rpm
4,0K /var/lib/synaptic
4,0K /var/lib/tlp
4,0K /var/lib/udisks2
4,0K /var/lib/update-rc.d
4,0K /var/lib/usb_modeswitch
4,0K /var/local
4,0K /var/log/apparmor
4,0K /var/log/private
4,0K /var/mail
4,0K /var/opt
4,0K /var/spool/rsyslog
8,0K /var/cache/PackageKit
8,0K /var/lib/dbus
8,0K /var/lib/gems
8,0K /var/lib/geoclue
8,0K /var/lib/logrotate
8,0K /var/lib/plymouth
8,0K /var/lib/private
8,0K /var/lib/pycentral
8,0K /var/lib/urandom
8,0K /var/lib/vim
8,0K /var/lib/xfonts
8,0K /var/lib/xkb
8,0K /var/tmp/systemd-private-3ecf013813a34996b0047062cdfed3fc-colord.service-DfE4YE
8,0K /var/tmp/systemd-private-3ecf013813a34996b0047062cdfed3fc-iio-sensor-proxy.service-sWuJZl
8,0K /var/tmp/systemd-private-3ecf013813a34996b0047062cdfed3fc-rtkit-daemon.service-i3LMOt
8,0K /var/tmp/systemd-private-3ecf013813a34996b0047062cdfed3fc-systemd-timesyncd.service-uxZJie
8,0K /var/tmp/systemd-private-3ecf013813a34996b0047062cdfed3fc-upower.service-9c6Kr2
12K /var/lib/apparmor
12K /var/lib/grub
12K /var/lib/initramfs-tools
12K /var/lib/msttcorefonts
12K /var/lib/runit
12K /var/lib/sgml-base
12K /var/lib/snmp
12K /var/log/fsck
16K /var/cache/lightdm
16K /var/lib/binfmts
16K /var/lib/debian-security-support
16K /var/lib/libreoffice
16K /var/lib/sudo
16K /var/spool/libreoffice
20K /var/cache/localepurge
20K /var/lib/libxml-sax-perl
20K /var/spool/anacron
24K /var/lib/emacsen-common
24K /var/lib/pulse
28K /var/lib/alsa
28K /var/lib/pam
28K /var/spool/cron
32K /var/lib/bluetooth
32K /var/lib/freevo
36K /var/lib/dictionaries-common
36K /var/lib/exim4
36K /var/lib/PackageKit
36K /var/lib/xml-core
40K /var/cache/powertop
40K /var/spool/exim4
44K /var/lib/polkit-1
48K /var/cache/dictionaries-common
48K /var/log/exim4
56K /var/lib/colord
64K /var/lib/ghostscript
72K /var/lib/NetworkManager
88K /var/log/cups
112K /var/lib/ucf
136K /var/cache/ldconfig
152K /var/lib/AccountsService
160K /var/log/apt
188K /var/cache/system-tools-backends
356K /var/lib/gconf
444K /var/lib/systemd
460K /var/cache/cracklib
500K /var/cache/samba
600K /var/lib/usbutils
732K /var/lib/btscanner
756K /var/lib/upower
1,4M /var/lib/sddm
1,6M /var/cache/man
1,7M /var/lib/lightdm
1,9M /var/cache/minidlna
2,3M /var/lib/samba
2,6M /var/lib/ispell
3,0M /var/log/samba
5,5M /var/log
6,0M /var/cache/cups
6,2M /var/cache/apparmor
6,5M /var/lib/smartmontools
8,3M /var/cache/debconf
13M /var/tmp
14M /var/lib/mlocate
17M /var/lib/aspell
19M /var/backups
29M /var/spool
29M /var/spool/cups
59M /var/cache/fontconfig
91M /var/lib/dpkg
214M /var/cache/apt
297M /var/cache
964M /var/lib/apt
1,1G /var/lib
root@debian:~#

Pas de là

fp2@debpacha:~$ du -sh /usr
4,2G	/usr
fp2@debpacha:~$ 

Pour avoir la liste des paquets qui prennent le plus de place

fp2@debpacha:~$ dpigs 
188502 linux-image-4.9.0-8-amd64
188341 linux-image-4.9.0-7-amd64
182276 linux-image-4.8.0-2-amd64
160287 firefox-esr
152579 libvtk6.3
151999 libopenfoam
119309 libreoffice-core
114081 libboost1.62-dev
113969 openfoam
113473 libgl1-mesa-dri

fp2@debpacha:~$ dpkg-query --search $(which dpigs)
debian-goodies: /usr/bin/dpigs
fp2@debpacha:~$ 

Il se pourrait bien qu’il y ait des fichiers temporaires en masse

Quel genre de machine ? Combien de mémoire vive ? D’où sortent ces syt_mes de fichiers tmpfs de 63G ?

fp2@debpacha:~$ df -hT /run
Sys. de fichiers Type  Taille Utilisé Dispo Uti% Monté sur
tmpfs            tmpfs   788M    9,3M  778M   2% /run
fp2@debpacha:~$ 

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة


F. Petitjean
Ingénieur civil du Génie Maritime.

« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

Vous êtes tous bien gentils d’incriminer les programmes installés (/usr) ou les logs ou le cache APT (/var) mais le total du contenu des répertoires de la racine montrés dans le message initial se monte à peine à 6 Go, on est encore très loin des 15 Go occupés.

Autres pistes :

  • espace occupé par des fichiers dans des répertoires de la racine non montrés (/tmp, /mnt…)

  • espace occupé par des fichiers supprimés mais encore ouverts -> redémarrer, ou tenter de les identifier avec lsof ou fuser

  • espace occupé par des fichiers masqués par un montage ; mon suspect principal est le partage réseau dans /mnt

  • espace occupé par des sous-volume ou snapshots si le système de fichiers racine est de type btrfs par exemple

Ça peut aller très vite en cas d’anomalie qui provoque l’enregistrement de messages en cascade dans les logs.

Possible, mais ce n’est dans /run qu’il faut les chercher puisque ce n’est pas dans le système de fichiers racine. Peut-être /tmp.

Les tmpfs sont créés avec la moitié de la RAM par défaut, donc 64 Go si la machine a 128 Gio de RAM.

1 J'aime

c est clair on se laisse aller
mais il n’a pas écrit la commande qu’il a utilisé, donc on ne sait pas

Merci pour vos réponses toutes très intéressantes,
Alors la commande que j’ai utilisé c’est bien
#du -hs
Et le serveur a bien 128Go de ram, mais ce qui me parait bizarre c’est que ma partition /racine fait bien 20Go et 15Go sont utilisé mais si on additionne /usr, /var, /tmp, /bin, /sbin, /lib, /lib64, /root
on est pas du tout à 15Go, donc ou se trouve cette difference ? un processus peut etre ?

Ça m’étonnerait. Cette commande ne donne pas du tout ce type de résultat. Elle ne donne que l’occupation totale du répertoire courant et de ses sous-répertoires, pas l’occupation pour chaque répertoire de la racine. D’autre part il manque des répertoires comme /mnt et /tmp.
Donne le résultat de la commande suivante en root pour être sûr que tu n’as rien oublié :
du -hxd1 / | sort -h

Si c’est bien la commande que j’ai effectué, voici le résultat de ta commande qui ne fonctionne pas:
du -hxd1 / | sort -h
du: avertissement : conflit avec --max-depth=1 à la génération du résumé
Saisissez « du --help » pour plus d’informations.

“Ma” commande fonctionne, je l’utilise souvent.
Cet avertissement ne se produit qu’avec l’option -s (résumé), présente dans ta commande originelle mais pas dans la mienne, et qui est en conflit avec l’option -d (limiter la profondeur).

Oui effectivement j’avais un alias pour la commande “du”
Voici le resultat:
# du -hxd1 / | sort -h
4,0K /lib64
4,0K /mnt
4,0K /opt
8,0K /media
12K /srv
16K /lost+found
200K /tmp
8,1M /root
8,9M /bin
18M /etc
22M /boot
23M /sbin
40M /lib
1,4G /usr
4,3G /var
5,8G /

Donc les 11 Gio manquants ne sont pas dans le contenu visible des répertoires de la racine.
df affiche-t-il encore 15 Gio utilisés après redémarrage du système (donc pas de fichier supprimé encore ouvert) ?
Si oui, le système de fichiers racine supporte-t-il des fonctionnalités de type sous-volume ou snapshot/instantané (btrfs, zfs…) ?
Si non, peux-tu démonter /mnt/FTPBackup et /home (en session console root directement, sans passer par une session utilisateur) pour voir ce qu’il y a dessous ?

Oui df affiche encore 15Go, alors je n’ai pas tenté de redemarrage encore mais si je demonte /home et /mnt/ftpbackup qui est en fait un lecteur reseau NFS, cela ne change rien.
Il n’y a pas de sous-volume ou snapshot.
Faudrait que je fasse un reboot dans le week-end, pour voir ce qu’il ce passe.

Evidemment puisque leur taille n’est pas comptée dans l’utilisation de la racine. Il ne suffit pas de les démonter, il faut ensuite regarder ce qu’il y a sous les points de montage, directement ou en relançant “ma” commande du.

Donc j’ai bien relancé la commande et c’est exactement la même chose.
4,0K /lib64
4,0K /opt
8,0K /media
8,0K /mnt
12K /srv
16K /lost+found
200K /tmp
8,1M /root
8,9M /bin
18M /etc
22M /boot
23M /sbin
40M /lib
1,4G /usr
4,3G /var
5,8G /
On ne sait toujours voir d’ou ça vient !

Pas tout-à-fait, la taille de /mnt a changé, ce qui est normal.
Par contre pourquoi /home n’apparaît-il jamais ?

Je ne sais pas. Pourtant elle est bien montée:
# mount | grep home
/dev/md3 on /home type ext4 (rw,relatime,quota,usrquota,grpquota,data=ordered)