Luna - Disque plein sans raison

Matériel Jeedom - Hardware La Box JEEDOM LUNA
1

Bonjour,

J’ai migré récemment de SMART à LUNA.
Je retrouve ma LUNA avec un disque saturée à 100% et je n’arrive pas à trouver la raison.
Et dès que je libère de la place ça fond à vue d’oeil.

root@JeedomLuna:/var/www/html/plugins/zwavejs/resources# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        979M     0  979M   0% /dev
overlay          14G   13G   13M 100% /
tmpfs           980M     0  980M   0% /dev/shm
tmpfs           392M   41M  352M  11% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           4.0M     0  4.0M   0% /sys/fs/cgroup
tmpfs           256M  3.5M  253M   2% /tmp/jeedom
tmpfs           196M  8.0K  196M   1% /run/user/0

Les 2 plus gros dossiers sont /var et /usr mais ça reste faible par rapport au 16G du disque

root@JeedomLuna:/var/www/html/plugins/zwavejs/resources# du -hs /* | sort -nr | head -n10
513M	/swapfile
250M	/opt
66M	/root
41M	/run
16K	/i18n
8.9M	/tmp
5.0K	/home
4.0K	/media
3.4M	/etc
2.9G	/usr
2.2G	/var

Il n’y a pas de très gros fichiers non plus

root@JeedomLuna:/var/www/html/plugins/zwavejs/resources# find / -type f -size +100M -ls
   651525 524292 -rw-------   1 root     root     536870912 Mar  2  2023 /swapfile
    11099 209484 -rwxr-xr-x   1 root     root     214504440 Jan 16  2024 /usr/lib/chromium/chromium
   652705 122772 -rwxrwxr-x   1 www-data www-data 125711576 Dec  2 01:01 /var/www/html/backup/backup-Maison-4.4.19-2024-12-02-01h59.tar.gz
   652796 122784 -rwxrwxr-x   1 www-data www-data 125726493 Dec  2 09:33 /var/www/html/backup/backup-Maison-4.4.19-2024-12-02-10h31.tar.gz

Des idées de ce que je loupe ?

Nico

2

Que donne un

du -ks *

Fait à la racine

Edit : je viens de voir que tu l’as déjà donné

Tu as rebooté ? Dans certaines circonstances (rotations de log), des fichiers peuvent être supprimés mais l’espace pas libéré

Norbert

3

Pas beaucoup plus d’info

root@JeedomLuna:/# du -khs *
0	bin
0	boot
0	dev
3.4M	etc
5.0K	home
16K	i18n
0	lib
0	lost+found
4.0K	media
0	mnt
250M	opt
du: cannot access 'proc/1130239': No such file or directory
du: cannot access 'proc/1130247/task/1130247/fd/3': No such file or directory
du: cannot access 'proc/1130247/task/1130247/fdinfo/3': No such file or directory
du: cannot access 'proc/1130247/fd/3': No such file or directory
du: cannot access 'proc/1130247/fdinfo/3': No such file or directory
0	proc
66M	root
41M	run
0	sbin
0	srv
513M	swapfile
0	sys
8.8M	tmp
0	userdata
du: cannot access 'usr/share/cdbs/1/rules/buildcore.mk': No such file or directory
du: cannot access 'usr/share/cdbs/1/rules/buildvars.mk': No such file or directory
du: cannot access 'usr/share/cdbs/1/rules/debhelper.mk': No such file or directory
du: cannot access 'usr/share/cdbs/1/rules/dpatch.mk': No such file or directory
du: cannot access 'usr/share/cdbs/1/rules/simple-patchsys.mk': No such file or directory
du: cannot access 'usr/share/cdbs/1/rules/tarball.mk': No such file or directory
du: cannot access 'usr/share/cdbs/1/rules/upstream-tarball.mk': No such file or directory
du: cannot access 'usr/share/cdbs/1/rules/utils.mk': No such file or directory
2.9G	usr
2.2G	var
root@JeedomLuna:/#
4

Et

ls -ltr

A la racine

5 
root@JeedomLuna:/# ls -lthr
total 513M
dr-xr-xr-x 186 root     root        0 Jan  1  1970 proc
drwxr-xr-x   2 root     root        3 Mar 19  2022 boot
drwx------   2 root     root        3 Jun 22  2022 lost+found
lrwxrwxrwx   1 root     root        8 Jun 22  2022 sbin -> usr/sbin
lrwxrwxrwx   1 root     root        7 Jun 22  2022 lib -> usr/lib
lrwxrwxrwx   1 root     root        7 Jun 22  2022 bin -> usr/bin
drwxr-xr-x   2 root     root        3 Jun 22  2022 srv
drwxr-xr-x   2 root     root        3 Jun 22  2022 mnt
drwxrwxr-x   1 www-data www-data 4.0K Jun 22  2022 media
drwxr-xr-x   3 root     root       25 Jun 22  2022 home
drwxr-xr-x   2 root     root        3 Jul  6  2022 userdata
drwxr-xr-x   1 root     root     4.0K Mar  2  2023 var
drwxr-xr-x   1 root     root     4.0K Mar  2  2023 usr
-rw-------   1 root     root     512M Mar  2  2023 swapfile
drwx------   1 root     root     4.0K Nov 30 13:22 root
drwxr-xr-x   2 root     root     4.0K Nov 30 13:50 i18n
drwxr-xr-x   1 root     root     4.0K Nov 30 14:54 opt
drwxr-xr-x   1 root     root     4.0K Dec  1 06:54 etc
drwxr-xr-x  14 root     root     3.5K Dec  1 17:57 dev
drwxr-xr-x  31 root     root      980 Dec 15 12:55 run
dr-xr-xr-x  14 root     root        0 Dec 15 12:55 sys
drwxrwxrwt   1 root     root     4.0K Dec 15 13:42 tmp
6

J’avais rajouté ceci dans mon post précédent

7

c’est une bonne idée même si mon disque est maintenant vraiment à 100% ?
J’ai peur de perdre complètement l’accès :slight_smile:

8

bon j’ai supprimé quelques fichiers et lancé un reboot …
Ca a effectivement libérer de l’espace

root@JeedomLuna:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        979M     0  979M   0% /dev
overlay          14G  4.6G  8.5G  35% /
tmpfs           980M     0  980M   0% /dev/shm
tmpfs           392M  1.3M  391M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           4.0M     0  4.0M   0% /sys/fs/cgroup
tmpfs           256M   84K  256M   1% /tmp/jeedom
tmpfs           196M  8.0K  196M   1% /run/user/0

Comment prévenir ça dans le futur ? et identifier la root-cause ?

1 « J'aime »
9

ce pb est lié à la suppression de fichiers qui sont encore ouverts par un autre processus.
Tant que le processus n’a pas « laché » le fichier, l’espace restera « occupé » dans le file system (coté df), mais comme le fichier est supprimé, tu ne le verras pas (coté commande du ou ls)
ca arrive souvent avec des fichiers de log volumineux apache ou mysql par exemple …
La problématique principale est de trouver le ou les fichiers qui sont capable de t’occuper + de 8Go !!
Donc suivre l’évolution de l’espace disque (df) pour voir si ca augmente beaucoup
ensuite, pour détecter les fichiers qui posent pb :

sudo lsof 2>/dev/null | grep deleted

(la 3eme colonne en partant de la fin représente la taille du fichier concerné)
Tu auras ainsi les process concernés.
Il est normal d’avoir des fichiers dans cette situation. ce qui est anormal, c’ets d’avoir des fichiers de plusieurs giga. C’est aussi pour ca que normalement, on vide les fichiers plutôt que de les effacer
Ensuite, en fonction du process, on verra les solutions

Norbert

10

Merci ! Pour l’instant ça ne semble pas bouger … je vais continuer de vérifier régulièrement

11

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.