Bonjour,

Mon serveur Debian se rempli anormalement rapidement tous les 2 jours. Je supprimais donc les logs qui pesait des Go mais maintenant, je suis encore à 100% mais ce ne sont plus les logs qui posent problème.

Je n'arrive pas à trouver :

- L'origine du problème

- Les fichiers les plus lourds de la machine

Pouvez-vous m'orienter svp ?

Salut,

Tu peux faire la commande suivante pour trouver où ton disque dur est rempli :

sudo du -h /répertoire

En commençant par la racine / puis en continuant progressivement dans les répertoires lourds.

Salut Typhlos,

Je viens de vérifier un à un les dossiers :

J'ai donc uniquement 4Go, quand je vérifie mes dossiers.

Cependant, c'est le SDA1 qui est à 100% d'utilisation, c'est peut être autre chose qui rempli l'espace non ? Je ne m'y connais pas trop en système linux.

root : df -h

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev              1002M       0 1002M   0% /dev
tmpfs              202M     21M  181M  11% /run
/dev/sda1           40G     38G     0 100% /
tmpfs             1010M       0 1010M   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs             1010M       0 1010M   0% /sys/fs/cgroup
tmpfs              202M       0  202M   0% /run/user/0

C'est étonnant... Peux-tu poster directement le retour de :

sudo du -sh /*

root:/# du -sh /*
9,0M    /bin
51M     /boot
0       /dev
8,2M    /etc
4,0K    /form.php
24K     /home
0       /initrd.img
0       /initrd.img.old
306M    /lib
16K     /lost+found
8,0K    /media
4,0K    /mnt
730M    /opt
0       /phpmyadmin
du: impossible d'accéder à '/proc/30514/task/30514/fd/3': Aucun fichier ou dossier de ce type
du: impossible d'accéder à '/proc/30514/task/30514/fdinfo/3': Aucun fichier ou dossier de ce type
du: impossible d'accéder à '/proc/30514/fd/3': Aucun fichier ou dossier de ce type
du: impossible d'accéder à '/proc/30514/fdinfo/3': Aucun fichier ou dossier de ce type
0       /proc
128K    /root
21M     /run
6,2M    /sbin
42M     /srv
0       /sys
1,1M    /text
40K     /tmp
1,4G    /usr
1,5G    /var
0       /vmlinuz
0       /vmlinuz.old

Ça m'étonne toujours. Notamment avoir un /bin et /etc aussi légers me parait bizarre. Que donne :

ls -alh /

-
Edité par Typhlos 18 janvier 2019 à 14:22:29

root:/# ls -alh /

total 1,2M
drwxr-xr-x  21 root root 4,0K janv. 17 16:13 .
drwxr-xr-x  21 root root 4,0K janv. 17 16:13 ..
drwxr-xr-x   2 root root 4,0K juil.  4  2017 bin
drwxr-xr-x   3 root root 4,0K juil.  4  2017 boot
drwxr-xr-x  16 root root 3,0K déc.  21 14:00 dev
drwxr-xr-x  98 root root 4,0K oct.  29 11:24 etc
-rw-r--r--   1 root root  143 mars   6  2017 form.php
drwxr-xr-x   3 root root 4,0K déc.  14  2015 home
lrwxrwxrwx   1 root root   31 juil.  4  2017 initrd.img -> boot/initrd.img-4.9.0-3-686-pae
lrwxrwxrwx   1 root root   32 juil.  4  2017 initrd.img.old -> boot/initrd.img-3.16.0-4-686-pae
drwxr-xr-x  16 root root 4,0K janv. 17  2018 lib
drwx------   2 root root  16K déc.  14  2015 lost+found
drwxr-xr-x   3 root root 4,0K déc.  14  2015 media
drwxr-xr-x   2 root root 4,0K déc.  14  2015 mnt
drwxr-xr-x   4 root root 4,0K janv. 17  2018 opt
lrwxrwxrwx   1 root root   21 sept. 15  2017 phpmyadmin -> /usr/share/phpmyadmin
dr-xr-xr-x 120 root root    0 déc.  21 13:59 proc
drwx------   5 root root 4,0K janv. 18 13:38 root
drwxr-xr-x  22 root root  780 janv. 18 13:38 run
drwxr-xr-x   2 root root 4,0K janv. 17  2018 sbin
drwxr-xr-x   4 root root 4,0K janv. 17  2018 srv
dr-xr-xr-x  13 root root    0 déc.  21 13:59 sys
-rw-r--r--   1 root root 1,1M janv. 17 16:13 text
drwxrwxrwt   9 root root 4,0K janv. 18 14:17 tmp
drwxr-xr-x  10 root root 4,0K déc.  14  2015 usr
drwxr-xr-x  13 root root 4,0K déc.  14  2015 var
lrwxrwxrwx   1 root root   28 juil.  4  2017 vmlinuz -> boot/vmlinuz-4.9.0-3-686-pae
lrwxrwxrwx   1 root root   29 juil.  4  2017 vmlinuz.old -> boot/vmlinuz-3.16.0-4-686-pae

-
Edité par Martin40 18 janvier 2019 à 14:24:32

Là c'est moi qui fait une erreur et qui oublie que sous Linux tout est fichier donc ls va renvoyer la taille du fichier qui représente le dossier plutôt que la taille du dossier en lui-même. Il faut que je creuse un peu de mon côté

du -sh /var/* est plus intéressant. En effet je pense que les logs sont pour cause.

Le plus simple est de configurer systemd-journald pour mettre une taille maximale. Voir le man journald.conf

@Markand,

root:/# du -sh /var/*

7,4M    /var/backups
987M    /var/cache
327M    /var/lib
4,0K    /var/local
0       /var/lock
20M     /var/log
1,4M    /var/mail
4,0K    /var/opt
0       /var/run
2,6M    /var/spool
264K    /var/tmp
18M     /var/webmin
91M     /var/www

Pas grand chose non plus.

Le cache est grand, je me demande ce qu'il y a dedans.

tu peux faire un sudo apt autoclean pour vider le cache de apt.

Pense à lancer la commande du en root, sinon tous les fichiers ne seront pas pris en compte. Et mettre l'option -c pour avoir le total de la place utilisée.

@jo_link_noir,

J'effectuerais ta commande plus tard, car..

Bizarrement, l'espace s'est libéré tout seul ce week end... je ne comprends pas.

root@:~# df -h

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev              1002M       0 1002M   0% /dev
tmpfs              202M     21M  181M  11% /run
/dev/sda1           40G     24G   14G  64% /
tmpfs             1010M       0 1010M   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs             1010M       0 1010M   0% /sys/fs/cgroup
tmpfs              202M       0  202M   0% /run/user/0

C'est redescendue à 64% d'utilisation.

Sans doutes des timer/cron qui effacent justement le cache de temps à autre.

Je reviens après pile 1 an car j'ai eu exactement le même soucis.

Pas de fichier volumineux en vu mais en effectuant un redémarrage du syslog, j'ai récupéré 90% de mon espace disque, ça pourra en aider d'autres.

/etc/init.d/rsyslog stop
/etc/init.d/rsyslog start

Cordialement,