J’ai remarqué que le log cron_execution comportait de façon aléatoire des messages d’erreurs xxxx|sh: 1: sudo: Argument list too long et j’en ai recherché l’origine.
Après investigation, j’ai trouvé que la procédure chunkLog de la classe log était à l’origine de ces erreurs.
En effet, la méthode utilisée pour épurer les logs utilise un pipe qui contient l’ensemble des lignes du fichier log, ce qui est trop pour un shell unix. De fait, l’instruction échoue et le fichier log est remis à zéro et non tronqué comme attendu. Ce comportement est peut être du à des paramètres pour la purge trop élevées. Ceux-ci sont définis dans la configuration Jeedom, dans mon cas 20 000 lignes et 10 Mo.
La bonne nouvelle est que le problème est corrigé dans la version de dev de Jeedom. Si vous voulez régler ce problème dès maintenant
Très mauvais conseil de donner un morceau de code à copier aléatoirement sur une installation sans savoir qui va faire exactement quoi sur quelle version…
Comment assurer la compatibilité dans ce cas là?
Si quelqu’un a les compétences pour faire cette action, il saura où trouver le code et il en prendra l’entière responsabilité.
Le bon conseil c’est d’inviter chacun à mettre à jour sa version du core dans un délai raisonnable après sa publication.
Actuellement garder une 4.4 n’est pas raisonnable.
Juste pour information le problème a été signalé en novembre 2025 et le correctif proposé est le fruit d’un travail collectif mais apparemment pas bien urgent à régler pour l’équipe Jeedom. On avait pas l’air d’être bien nombreux à avoir le problème ou du moins à l’avoir constaté.
Ca n’avait pas l’air bien urgent pour les utilisateurs surtout car la correction est restée un long moment sur une branche dédiée sans aucun retour qu’il soit positif ou négatif. Elle a finalement été basculée dans le code du core en cours de développement toujours sans retour quel qu’il soit.
Comme souvent, je crains qu’on ne sache réellement si la correction appliquée est bien fonctionnelle qu’une fois que ce sera déployé en stable.
Et depuis, plus aucun post de quelqu’un de l’équipe Jeedom pour indiquer que la réflexion est arrivé à son terme, qu’un fix a été produit et que vous attendez des retours quelque part.
Je m’attendais à ce que quelqu’un revienne sur le post pour m’informer, comme je le fais moi quand j’ai des demandes d’aide sur mes plugins. Quel est la démarche que vous attendez ? Encore une fois c’est surement que j’ai pas intégré une démarche du coup si tu l’as je suis preneur pour les prochaines fois.
Et sur le fond du problème, vous aviez probablement raison et je n’ai fais que redonner la raison. Il n’y a pas eu moult manifestations d’utilisateurs donc il n’y avait surement que peu d’impacts. A partir de là je sais pas si vous allez avoir beaucoup de retour positif ou négatif après un fix. Pas simple.
Même si la version finale du fix a eu du mal à arriver à terme, il me semble qu’il y a eu des retours y compris la confirmation que c’était prêt pour la prochaine version.
Juste pour signaler que j’ai copié la fonction chuckLog dans mon environnement de production et que je ne rencontre pas de problème: la réduction des fichiers log marche correctement et sans erreur dans mon cas, contrairement à la version en cours.
Oui bien sûr que j’avais vu ton post et encore merci pour ton implication. J’ai mis à jour la fonction avec celle du PR depuis un bon moment. Je n’ai pas fais de retour pour dire que ça fonctionnait (méa culpa) mais on avait déjà fait pas mal de tentatives avec les différentes propositions et j’avais bien confirmé que je n’avais plus de soucis.
Je pense que la difficultés pour l’équipe ça va être d’obtenir les fameux retours positifs qui reviennent souvent sur le tapis. L’équipe s’agace parce qu’ils font des actions mais n’ont pas de retours et ne trouve pas ça normal.
Donc pour rester sur ce sujet, si on se réfère à la doc
Il faudrait crée un sujet dédié pour chaque fix ou évolution du code V4 dans la partie Core V4 - Communauté Jeedom et qu’un maximum de monde viennent confirmer que ça fonctionne pour eux ?
Est-ce que l’on pourrait imaginer qu’un modo ou quelqu’un de l’équipe crée se fameux sujet quand ils attendent des retours sur une partie du code pour appuyer le fait qu’ils attendent des tests sur tel ou tel fix ?
Les bêta testeurs ont plus le réflexe, je pense, d’ouvrir des sujets quand ils ont testés et que quelque chose ne fonctionne pas mais pas vraiment quand ça marche bien, c’est peut-être autour de ça qu’il faudrait trouver un moyen d’être plus efficace, non ?
Je suis d’accord, mais vous n’auriez eu que ma réponse en gros donc surement pas à l’attendu quand on attends plusieurs retours pour confirmer quelque chose. Regarde, bernard.dandrea n’a pas vu mon sujet puisqu’il en a ouvert un autre.
Bon bref, c’est pas simple
Merci pour le fix qui sera donc dispo en stable sur la 4.6.0
moi je ne m’attends pas à ce qu’on créé systématiquement des sujets pour dire que tout va bien
en ce qui me concerne, ne t’en veux pas.
ca été un sujet laborieux à accoucher; et si vmt il était encore bloquant je suppose que quelqu’un se serait manifesté
c’est pas le role du modérateur je pense.
mais lorsqu’il y a besoin de retour, si je suis à l’origine du changement, je créé un sujet pour le demander (s’il n’existe pas encore); dernier exemple: Bloc scénario "Tant que"
Merci pour le fix qui sera donc dispo en stable sur la 4.6.0