Bonjour à tous,
J’ai eu récemment un problème similaire traité ici, mais il m’a fallu refaire une installation complète de Jeedom (et la cause n’a pas pu vraiment être identifiée !).
Je reviens donc sur ce sujet car j’ai de nouveau le même problème constaté aujourd’hui (Espace disque libre en chute libre) :
Je ne possède qu’un seul fichier de sauvegarde sur Jeedom (les autres sont enregistrés sur un serveur externe) et j’ai fait un ménage important afin d’épurer la base de données.
Lorsque j’effectue une recherche des fichier de plus de 100Mo, j’obtiens ceci :
find: '/proc/4104475/task/4104475/fd/6': No such file or directory
find: '/proc/4104475/task/4104475/fdinfo/6': No such file or directory
find: '/proc/4104475/fd/5': No such file or directory
find: '/proc/4104475/fdinfo/5': No such file or directory
/var/lib/mysql/ibdata1
/var/www/html/backup/backup-AtlasDom-4.5.2-2026-01-17-07h34.tar.gz
/usr/bin/node
/usr/lib/chromium/chromium
Le fichier backup fait environ 230Mo, donc rien d’anormal.
Quelqu’un pourrait-il me donner une piste pour trouver l’origine la perte d’espace disque ?
Merci d’avance à tous et bon week-end !
Dom.
Déja c’est pas l’idéal de répondre à un message vieux de plus d’un an pour un « pb similaire ».
Rien n’indique que la root cause soit la même, même si les conséquences le sont.
Je te déconseille de chercher les fichiers les plus lourds mais plutot traiter par répertoire.
Tu peux par exemple avoir 1000 fichiers logs de 2Mo dans un répertoire qui vont représenter 2Go mais passer sous le radar car les fichiers individuels ne sont pas si gros que ça.
Pour ta recherche je commencerai par voir le résultat de :
J’ai aussi recherché des infos de dossiers lourdement remplis à l’aire de ndcu / et je suis sur la piste du fichier /var/lib/mysql/ibdata1 qui fait plus de 2.4Go.
Quelqu’un sait à quoi il sert et s’il peut être supprimé ?
Merci.
Dom.
sudo ls -alh /var/lib/mysql
total 2.4G
drwxr-xr-x 5 mysql mysql 4.0K Dec 27 13:44 .
drwxr-xr-x 38 root root 4.0K Jan 8 2024 ..
-rw-rw---- 1 mysql mysql 16K Jan 15 12:05 aria_log.00000001
-rw-rw---- 1 mysql mysql 52 Jan 15 12:05 aria_log_control
-rw-r--r-- 1 root root 0 Jan 8 2024 debian-10.5.flag
-rw-rw---- 1 mysql mysql 17K Dec 27 13:43 ib_buffer_pool
-rw-rw---- 1 mysql mysql 2.4G Jan 17 15:43 ibdata1
-rw-rw---- 1 mysql mysql 32M Jan 17 15:50 ib_logfile0
-rw-rw---- 1 mysql mysql 12M Dec 27 18:58 ibtmp1
drwx------ 2 mysql mysql 4.0K Jan 17 01:56 jeedom
-rw-rw---- 1 mysql mysql 0 Aug 19 2021 multi-master.info
drwx------ 2 mysql mysql 4.0K Aug 19 2021 mysql
-rw-rw---- 1 mysql mysql 15 Jan 8 2024 mysql_upgrade_info
drwx------ 2 mysql mysql 4.0K Apr 9 2024 performance_schema
À ma connaissance, non.
Une chose à remarquer néanmoins, la sauvegarde est programmée tous les jours à 2h00 et le fichier de sauvegarde est lui daté à 7h34 (environ).
Est-ce que ça pourrait être une piste ?
Alors, ce matin impossible de me connecter à Jeedom et un message indiquait que l’Espace disque libre était à 0%. Cependant, les scénarios semblaient fonctionner (VR…).
J’ai débranché la box Atlas, puis rebranché.
Oh miracle ! La connexion est redevenue possible et j’obtiens un tableau de santé correct :
En revanche, je constate un comportement particulier du log du plugin mymodbus_daemon qui ne cesse de produire des erreurs (de connexions ?) du style :
0000|[2026-01-18 10:01:18] ERROR : Fatal error: protocol.data_received() call failed.
0001|protocol: <pymodbus.transaction.transaction.TransactionManager object at 0xffffa77d5a90>
0002|transport: <_SelectorSocketTransport fd=8 read=polling write=<idle, bufsize=0>>
0003|Traceback (most recent call last):
0004|File "/opt/pyenv/versions/3.11.14/lib/python3.11/asyncio/selector_events.py", line 1013, in _read_ready__data_received
0005|self._protocol.data_received(data)
0006|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 304, in data_received
0007|self.datagram_received(data, None)
0008|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/transport/transport.py", line 338, in datagram_received
0009|cut = self.callback_data(self.recv_buffer, addr=addr)
0010|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0011|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/transaction/transaction.py", line 187, in callback_data
0012|used_len, pdu = self.framer.processIncomingFrame(self.trace_packet(False, data))
0013|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0014|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/framer/base.py", line 76, in processIncomingFrame
0015|data_len, pdu = self._processIncomingFrame(data[used_len:])
0016|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0017|File "/var/www/html/plugins/mymodbus/resources/venv/lib/python3.11/site-packages/pymodbus/framer/base.py", line 98, in _processIncomingFrame
0018|raise ModbusIOException("Unable to decode request")
0019|pymodbus.exceptions.ModbusIOException: Modbus Error: [Input/Output] Unable to decode request
Le fichier log ne cesse donc de grossir et pourrait être à l’origine de la saturation de l’espace disque.
