Attention ça ne fonctionne pas dans les fichiers de desktop etc
hors classe (oui logique mais c’est bien de le dire
)
J’ai le meme soucis.
Pour info, j’ai créé une PR, car le code présent sur develop ne réglait pas le problème : Fix aléatoire du vidage des logs et préservation des Inodes by scanab · Pull Request #3266 · jeedom/core · GitHub
Le problème vient de la ligne
echo "$(tail -n ' . $maxLineLog . ' ' . $_path . ')" > ' . $_path
Dans la commande : echo "$(tail ...)" > log.txt
- Le shell prépare la redirection > avant d’exécuter le contenu de la parenthèse $().
- Il ouvre le fichier en mode écriture, ce qui le vide (0 octet).
- Si le processeur est rapide : tail a déjà chargé les lignes en mémoire vive (RAM) avant que le fichier ne soit physiquement vidé sur le disque. Le echo réécrit alors les lignes stockées en RAM. Ça marche.
- Si le système est chargé (CPU/Disque occupé) : Le fichier est vidé par le > mais le tail prend quelques millisecondes de trop pour démarrer. Quand il essaie de lire, le fichier est déjà vide. tail renvoie « rien », et echo « » écrase tout.
La charge système est déterminante, d’où le coté aléatoire.
Bonjour,
-
Ce post de Loic à prendre en compte pour la préservation des cartes SD:
Jeedom 4.5 - un manque de logs après le passage du crondaily - #26 par Loic
Je l’avais résolu en créant le fichier temporaire réduit à 10Mo dans un tempfs. (self::getConfig('maxSizeLog', '10');) depuis la 4.5.3 -
A propos de :
catch (\Exception $e) {
// Gestion d'erreur silencieuse conforme à l'existant
}
Dans un premier temps, il faudrait afficher les erreurs. Ca permettrait de les capter et les corriger:
Ex: Jeedom 4.5 - un manque de logs après le passage du crondaily - #34 par jpty
-
Pourquoi ne pas avoir testé ce qui est 2 posts au dessus du votre et avoir refait une variante ?
-
Sinon la PR ne passera jamais à cause de la présence de commentaires (de plus en francais).

Je me répète, pourquoi ne pas faire une PR alors?
Y avait une raison pour avoir viré les droits sur le fichier dans la nouvelle version?
On n’a pas le droit de mettre des commentaires dans une PR ?
Bonjour,
Tout est exécuté avec sudo. Inutile de changer les droits, propriétaire…
Quelqu’un est contre faire un bash -o pipefail rapport au dernier review de copilot?
The pipeline
tail -c ... | tail -n ... > tmpdoes not usepipefail, so failures in the firsttail -ccan be masked by the secondtail -nexiting successfully. In that case, the tmp file may be incomplete/empty andcat tmp > originalwould still overwrite the log. Run the pipeline underbash -o pipefail -c ...(or otherwise ensure pipeline failures propagate) before overwriting the original file.
Jamais utilisé pipefail.
J’ai demandé à ChatGPT de me l’expliquer et il semble d’accord pour éviter toute corruption du fichier de log.
La version de référence est à présent ici: Fix aléatoire du vidage des logs et préservation des Inodes by scanab · Pull Request #3266 · jeedom/core · GitHub
je souhaite qu’il n’y ait plus de proposition de code ailleurs que sur cette PR afin d’avoir un suivi centralisé (ok pour avoir une feedback générale ici, mais je n’ai plus envie de faire de copier/coller de code un peu partout pour rassembler les morceaux de code de chacun…)
Vu les derniers changements sur la fonction, j’attends et j’espère avoir des retours sur son fonctionnement de plusieurs personnes avant que l’on valide la PR et qu’elle soit merge définitivement au core
edit: s’il faut, si plusieurs personnes veulent collaborer sur ce fix, si on repère encore des modifs à faire, je peux créer une branche dédiée sur le repo du core afin que chacun puisse soumettre des PR (sur la potentielle branche du fix), faites moi signe ici et ca sera fait.
Bonjour,
Je veux bien une branche. Ca devient compliqué dans la PR.
J’ai une PR possible sur une optimisation: Ne rien faire tant que l’un des seuils taille et nombre de lignes n’est pas atteint. Actuellement le fichier est toujours réécrit.
Et le retour de -o pipefail fonctionnel.
J’ai créé une branche dédié pour ce fix sur GitHub - jeedom/core at fix/chunk-log · GitHub et j’ai merge les changements de la PR en cours dedans
je rappelle pour ceux qui veulent tester ce fix (sur un jeedom de test, qui peut être « cassé », cela reste risqué d’utiliser une autre version que la version stable), il suffit d’aller dans la config market et de choisir la version « fix/chunk-log » => faire une mise à jour du core ensuite même si rien n’est proposé, il n’y pas de proposition de mise à jour sur les versions autres que « stable »
