Je suis passé en 4.5 il y a quelques jours, j’ai voulu examiner un comportement anormal et je me rends compte que la plupart des logs n’ont plus grand chose dedans.
Exemple avec un scénario qui tourne chaque jours à 10h
J’ai essayé de « Télécharger » les logs en me disais qu’il y avait peut-être le reste dedans mais c’est pas le cas.
Il y a une refonte des logs dans la 4.5 :
Refonte de l’écriture dans les logs, suppression de la bibliothèque monolog (attention l’option d’envoi des logs dans syslog n’est plus disponible pour le moment, si la demande est forte nous verrons pour la remettre)
Je n’ai pas eu d’erreur lors de la mise à jour donc je ne me sent pas concerné par cette phrase :
Dû à la refonte des logs et la réinternalisation de bibliothèques, lors de la mise à jour vous pouvez avoir une erreur type PHP Fatal error (rien de grave) il suffit de relancer la mise à jour.
Est-ce que vous pourriez regardez dans vos scénarios si vous avez le même soucis ?
J’ai un scénario qui se déclenche toutes les 15 s en moyenne !
Log dans la fenêtre Jeedom = 500 lignes (comme paramétré)
Log téléchargé environ 23 000 lignes !
Même comportement que DanielJ, tout est ok chez moi.
Extrait d’un log sur le control de l’état d’un module :
------------------------------------
[2025-11-29 09:00:07][SCENARIO] -- Début : . Tags : {"#trigger#":"other","#trigger_name#":"","#trigger_id#":"","#trigger_message#":"Lancement provoqué","#trigger_value#":""}
[2025-11-29 09:00:07][SCENARIO] - Exécution du sous-élément de type [action] : action
[2025-11-29 09:00:07][SCENARIO] Pause de 10 seconde(s)
[2025-11-29 09:00:17][SCENARIO] - Exécution du sous-élément de type [condition] : if #[Chauffage][Thermostat][Actif]# != #[Chauffage][2 - Qubino Flush 1D relay ZMNHND - Chaudière][Etat]#
[2025-11-29 09:00:17][SCENARIO] Evaluation de la condition : [1 != 1] = Faux
[2025-11-29 09:00:17][SCENARIO] - Exécution du sous-élément de type [action] : else
[2025-11-29 09:00:17][SCENARIO] Exécution de la commande [Jeedom][PlayMP3][Lecture Fichier] avec comme option(s) : {"background":"0","title":"","message":"\/var\/www\/html\/plugins\/playtts\/data\/sons\/thermostat.wav"}
[2025-11-29 09:00:18][SCENARIO] Fin correcte du scénario
------------------------------------
[2025-11-29 09:03:04][SCENARIO] -- Début : . Tags : {"#trigger#":"other","#trigger_name#":"","#trigger_id#":"","#trigger_message#":"Lancement provoqué","#trigger_value#":""}
[2025-11-29 09:03:04][SCENARIO] - Exécution du sous-élément de type [action] : action
[2025-11-29 09:03:04][SCENARIO] Pause de 10 seconde(s)
[2025-11-29 09:03:14][SCENARIO] - Exécution du sous-élément de type [condition] : if #[Chauffage][Thermostat][Actif]# != #[Chauffage][2 - Qubino Flush 1D relay ZMNHND - Chaudière][Etat]#
[2025-11-29 09:03:14][SCENARIO] Evaluation de la condition : [0 != 0] = Faux
[2025-11-29 09:03:14][SCENARIO] - Exécution du sous-élément de type [action] : else
[2025-11-29 09:03:14][SCENARIO] Exécution de la commande [Jeedom][PlayMP3][Lecture Fichier] avec comme option(s) : {"background":"0","title":"","message":"\/var\/www\/html\/plugins\/playtts\/data\/sons\/thermostat.wav"}
[2025-11-29 09:03:14][SCENARIO] Fin correcte du scénario
------------------------------------
[2025-11-29 10:00:06][SCENARIO] -- Début : . Tags : {"#trigger#":"other","#trigger_name#":"","#trigger_id#":"","#trigger_message#":"Lancement provoqué","#trigger_value#":""}
[2025-11-29 10:00:06][SCENARIO] - Exécution du sous-élément de type [action] : action
[2025-11-29 10:00:06][SCENARIO] Pause de 10 seconde(s)
[2025-11-29 10:00:16][SCENARIO] - Exécution du sous-élément de type [condition] : if #[Chauffage][Thermostat][Actif]# != #[Chauffage][2 - Qubino Flush 1D relay ZMNHND - Chaudière][Etat]#
[2025-11-29 10:00:16][SCENARIO] Evaluation de la condition : [1 != 1] = Faux
[2025-11-29 10:00:16][SCENARIO] - Exécution du sous-élément de type [action] : else
[2025-11-29 10:00:16][SCENARIO] Exécution de la commande [Jeedom][PlayMP3][Lecture Fichier] avec comme option(s) : {"background":"0","title":"","message":"\/var\/www\/html\/plugins\/playtts\/data\/sons\/thermostat.wav"}
[2025-11-29 10:00:17][SCENARIO] Fin correcte du scénario
------------------------------------
[2025-11-29 10:08:03][SCENARIO] -- Début : . Tags : {"#trigger#":"other","#trigger_name#":"","#trigger_id#":"","#trigger_message#":"Lancement provoqué","#trigger_value#":""}
[2025-11-29 10:08:03][SCENARIO] - Exécution du sous-élément de type [action] : action
[2025-11-29 10:08:03][SCENARIO] Pause de 10 seconde(s)
[2025-11-29 10:08:13][SCENARIO] - Exécution du sous-élément de type [condition] : if #[Chauffage][Thermostat][Actif]# != #[Chauffage][2 - Qubino Flush 1D relay ZMNHND - Chaudière][Etat]#
[2025-11-29 10:08:13][SCENARIO] Evaluation de la condition : [0 != 0] = Faux
[2025-11-29 10:08:13][SCENARIO] - Exécution du sous-élément de type [action] : else
[2025-11-29 10:08:13][SCENARIO] Exécution de la commande [Jeedom][PlayMP3][Lecture Fichier] avec comme option(s) : {"background":"0","title":"","message":"\/var\/www\/html\/plugins\/playtts\/data\/sons\/thermostat.wav"}
[2025-11-29 10:08:14][SCENARIO] Fin correcte du scénario
Je « pense » que Défaut devrait être coché partout, je suis dans la même configuration que DanielJ, malgré cela, il semble bien que le niveau défaut soit pris en compte. A tester en forçant chez toi.
Mon scénario " SC Pilotage ECS avec routeur PV et BBR" est vide alors qu’il y avait bien des lignes de logs dans la journée d’hier après 10h (l’heure de programmation)
Pour moi c’est pas normal, il y a un truc qui ne va pas depuis le passage en 4.5 mais si ça marche comme il faut chez vous, c’est moins facile à identifier
C’est bien le crondaily qui fait visiblement ce boulot
Oui, c’est bien celui là.
Et comme ton log Scénario est Défaut et le log Défaut est Erreur:
AMHA ce n’est pas anormal qu’il n’y ait pas de log.
Avec les mêmes niveaux de log que toi, j’ai des logs à l’exécution du scénario.
A première vue je ne vois pas le rapport. Si le niveau de logs n’était pas bon, rien ne serait enregistré dans le log du scenario et ce n’est pas le problème ici.
Il est plus de 10h, est comme mon scénario s’est déclenché, il y a bien des logs dedans
Le problème se passe lors du crondaily, les logs sont purgés chez moi de façon très agressive et pour prendre l’exemple de ce scénario, il est totalement vidé
Oui je suis dessus depuis 20mn pour essayer de voir ce qui ne va pas …
Mais comme tu peux le voir sur ma capture des logs, il y a pas mal de logs qui sont traités à 02h57 et qui ne sont pas à 0 b
Et ceux là aussi ne sont pas bon car je n’efface jamais les logs de scénario et ils ne contiennent maintenant que quelques jours ou heures de logs tout en étant à bien moins de 10000 lignes chacun
J’ai bien conservé dans les logs les 500 lignes avant l’heure de remise à 0 (2h42 chez moi) bien que ma configuration des logs scénario soit aussi sur Défaut - Erreur.
Je viens de passer à 1250 lignes pour voir le résultat demain
Ne serait-ce pas le très grand nombre de lignes paramétré qui poserait problème ?
Je n’exclus rien mais pour moi c’est assez improbable, le code utilise la fonction « tail » de linux et je ne pense pas qu’elle pose problème d’autant plus qu’avant ça fonctionnait très bien.
J’ai été récupéré une ligne de code du core issue de la 4.4 histoire de voir ce que ça donne cette nuit.
Il y a 2 différences et maintenant en 4.5:
un passage sur les fichiers pour définir owner/group
A voir comment les daemons qui utilisaient ces logs vont se comporter puisque les fichiers qu’ils avaient ouverts ont changé.
Edit: avec mv fichier.tmp fichier, les daemons n’écrivent plus dans fichier. (Avec mv l’inode de fichier change)
Il faut :
Oui, je simplifiais un peu juste pour essayer de dire que je ne vois pas ce genre de commandes buguer pour 10000 lignes.
Bref ce matin comme fortement envisagé, le retour à la ligne de commande issue de la V4 a fonctionné comme il faut, pas de suppressions de logs, notamment dans ce scénario qui revenait systématiquement à zéro
Je vais tenter de rajouter la 1ere partie et ne pas faire l’echo avec le sudo …
Je ne vois pas en quoi la 1ere ou la 2eme partie pourrait poser problème mais c’est pourtant le cas.
Merci pour le passage de la commande dans une IA, ça sera à tester aussi
Je pense qu’il y a effectivement un pb avec le sudo echo tail ....
Pour les logs des fichiers qui avaient une certaine taille (~100ko et plus), le contenu du fichier log est après passage du cronDaily : sh: 1: sudo: Argument list too long
J’ai modifié ainsi pour améliorer la visibilité et simplifier :
$sudo = system::getCmdSudo(); // appelé plusieurs fois et ne change pas
$uid = system::get('www-uid'); // appelé plusieurs fois et ne change pas
$gid = system::get('www-gid'); // appelé plusieurs fois et ne change pas
try {
com_shell::execute("$sudo chmod 664 $_path > /dev/null 2>&1");
com_shell::execute("$sudo chown -R $uid:$gid $_path > /dev/null 2>&1");
// com_shell::execute($sudo .' echo "$(tail -n ' .$maxLineLog .' ' .$_path .')" > ' .$_path);
com_shell::execute("$sudo tail -n $maxLineLog $_path > $_path.tmp && cat $_path.tmp > $_path && rm $_path.tmp");
// com_shell::execute(system::getCmdSudo() . 'chmod 664 ' . $_path . ' > /dev/null 2>&1;'. system::getCmdSudo() . 'chown -R ' . system::get('www-uid') . ':' . system::get('www-gid') . ' ' . $_path.' > /dev/null 2>&1;'.system::getCmdSudo() . ' echo "$(tail -n ' . $maxLineLog . ' ' . $_path . ')" > ' . $_path);
} catch (\Exception $e) {
}
@chown($_path, $uid);
@chgrp($_path, $gid);
Oui, je confirme que c’est bon avec ce que j’avais mis hier et donc il ne reste plus que cette commande sudo echo "$(tail... qui ne fonctionne pas comme il faut. Sans le sudo c’est bon.
Merci d’avoir confirmé que c’était KO aussi chez toi, je ne comprends pas encore pourquoi tout le monde ici avait l’air de ne pas être impacté
Tu me diras ce que ça donne avec ton nouvel enchainement de commandes demain matin
