Depuis quelques jours je perds environ 1.5 % de volume disque toute les heures, le redémarrage de Jeedom résous le problème instantanément (cf la courbe verte du screen).
Mais redémarrer tous les jours … c’est pas glop !
Bonjour
Je comprends pas le soucis si tu dis qu’il n’y a pas disfonctionnement jeedom… Comme répété souvent linux ne libere de la mémoire que si besoin a la différence de windows il est donc normal d’avoir de la consommation mémoire qui se rapproche en permanence de 100%
Jusqu’à présent le volume disque dispo oscillait entre 30 et 48%, la il baisse drastiquement, je parle évidemment de volume disque (je me suis mal exprimé la première fois , pas de la MEM, c’est « /dev/sda1 » qui fond comme neige au soleil.
J’ai essayé de pister la perte de volume via « du » sans aucun succès, la taille des rep /user et /var donné par ‹ du › ne changeait pas d’un poil alors que la place libre sur le disque continuait à diminuer régulièrement.
J’ai cherché du coté des fichiers cachés, mais ils sont trop bien caché !!!
Alors je me suis souvenus que la dernière fois que j’avais eu ce problème je galérais avec des fichiers de log qui même sur « aucun » était envahissant … et @Loic avait écris quelque part qu’il allait les rediriger sur « null » .
Alors j’ai essayé et … BINGO , après avoir passé le log de OpenZwave (le plus bavard chez moi) de « Aucun » à « Error » et relancé le daemon j’ai retrouvé INSTANTANEMENT l’espace perdu sur le disque !!!.
J’ai remis le log à « Aucun » et relancé le daemon ==> et le volume libre à recommencé à baisser … CQFD
Je soupçonne donc le « trou noir » que devrais être le « null » de linux d’être dans ce cas plus une « matière noire encombrante quoique invisible » pour plagier Stephen Hawking !!!
Par contre il est intéressant de noter que la modif du type de log et la relance du daemon résolvent instantanément et totalement le problème. C’est donc surement gérable sans cette manip.
Ce serait bien de trouver une solution pérenne car cela peut provoquer des plantages lourd voir destructif en 1-3 jours pas évident à diagnostiquer pour ceux qui n’ont pas une fonction de suivi/alerte du volume libre.
Bonjour
Je vais regarder mais dans tout les cas tout changement de niveau de log doit absolument être suivi d’un redémarrage du démon quelques soit le démon on ne pourra jamais faire autrement.
C’est bien ce que j’ai fait oui évidemment, ça parait logique
mais je ne vois pas trop le rapport avec le bug évoqué
Par ailleurs je n’ai testé QUE avec OpenZwave quoique ce soit surement du à une fonction générique du core concernant les logs je ne peux pas exclure que se ne soit pas une des « nouvelles » particularités de OpenZwave
En faite c’est quand tu fais supprimer tous les logs et que le démon tourne le fichier est plus la sur le disque mais en faite si et il faut redémarrer le démon pour qu’il me lâche et que la place se libéré vraiment. Malheureusement je peux rien y faire
Désolé d’insister, mais c’est en passant le log sur « Aucun » et relance du démon que le problème se produit chez moi, si le log est sur ‹ error ›, plus de soucis, y compris en supprimant tout les logs (je l’ai encore fait cette nuit à 2:00)
La commande suivante permet de savoir tous les fichiers qui ont été supprimés (donc absent par le biais d’un ls) mais précédemment ouvert par un processus.
L’espace disque ne sera donc libéré qu’une fois le handle du fichier fermé par le processus.
lsof -a +L1
Un example sur une simple VM :
root@vps681002:~# lsof -a +L1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
mysqld 1876 mysql 7u REG 8,1 0 0 10134 /tmp/ibcHiSwl (deleted)
mysqld 1876 mysql 8u REG 8,1 0 0 10136 /tmp/ib0wbgxY (deleted)
mysqld 1876 mysql 9u REG 8,1 0 0 10138 /tmp/ibAk30ye (deleted)
mysqld 1876 mysql 13u REG 8,1 0 0 10140 /tmp/ibbAYtCR (deleted)
, pas de la MEM, c’est « /dev/sda1 » qui fond comme neige au soleil.
, après avoir passé le log de OpenZwave (le plus bavard chez moi) de « Aucun » à « Error » et relancé le daemon j’ai retrouvé INSTANTANEMENT l’espace perdu sur le disque !!!.