Programmation quotidienne KO depuis passage en v4.4.9

Bonjour à tous,

Je rencontre un souci suite passage en v4.4.9 :

→ Programmation quotidienne KO (identifié pour l’instant sur 2 scénarios).

Voici celui sur lequel je viens de refaire des tests :

Je pense à un bug (sauf si j’ai loupé un truc).
Qu’en pensez-vous ?

Merci.

Bonjour,
Bizarre ton truc le scénario doit s’éxecuter a 12h26 mais dans les logs je vois du 16h31. Tu as changé la programmation ?

Pour les heures « précèdent » « suivant » c’est pas les heures de lancement réel mais calculé a partir des programmations. C’est juste la pour t’aider a savoir quand ca va se lancer et voir si ton cron est bon.

Je viens de tester sur 5 jeedom la programmation horaire (14 14 * * * dans mon cas) et aucun soucis ca marche parfaitement comme attendu. Je pense donc plus a un soucis chez toi que a un bug jeedom, surtout un comme ca il y aurait une tonne de message sur le community et au support et ca serait deja corriger un bug aussi grave.

l’heure indiquée n’est pas forcément l’heure à laquelle le scénario s’est exécuté en réalité, c’est une heure calculée selon la programmation configurée, donc non ce n’est pas faux, c’est juste.

Compris.
C’est juste contenant le comportement de la programmation cron.
C’est ambigu car cela donne l’impression que le scénario s’est lancé.

Oui j’ai changé la programmation tout à l’heure pour lancer mes tests.

C’est que @Mips vient d’expliquer → bien compris.
Du coup, afficher « Précédent » n’est peut être pas utile, puisque cela prête à confusion ?

Merci. Je vais retester à partir d’un nouveau scénario, je vous dis ce qu’il en est.

Bon je viens de retester de zéro :

  • Création d’un nouveau scénario
  • Programmation quotidienne 15:12
  • Lancement manuel → OK
  • Lancement via cron - rien ne se passe

  • Comment puis-je vérifier / repérer la tâche cron créée ?
  • Y a-t-il autre chose que je puisse vérifier ?

ca n’existe pas…

la page santé jeedom; dois-je répéter que c’est utile voir nécessaire pour chaque demande?

Oui désolé la voici :
(le non à jour est le plugin klf200)

Mets aussi les logs scénario et cron exécution

Les voici :

scenario.log (4,7 Ko)

cron_execution.log (198,7 Ko)

C’est pas le bon log pour scenario.

Tu peux m’envoyer une capture du moteur de tache ?

Je me demande si tu as pas un cron mal formaté dans un scénario qui fait planter tout le truc.

Voici l’autre au ca où :
scenario_execution.log (88,4 Ko)

Voici en 3 fichiers pour que ce soit lisible :



Bonne idée ! A suivre…

Y’a un truc bizarre sur la tache cron scénario Check qui tourne depuis trop longtemps ça devrait pas durer plus de 20s. Essaye de la relancer pour voir.

Nickel :wave: :wave:
Je viens de tester à deux reprises, cela a fonctionné les deux fois !
On peut dire que c’est réparé ou il y a autre chose à faire ?

Pour comprendre :
-A quoi correspond cette tâche ?
-Peut-on identifier ce qui l’a mise en vrac ?

Cette tâche regarde les cron de chaque scénario et lance le scénario en question si c’est le moment.

Honnêtement faut surveiller la je pense je ne vois pas pourquoi ça arriverait plus. Je pense tu dois avoir un scénario programmé en mode direct qui prend du temps et donc retarde tous les scénarios

Que veux-tu dire par « mode direct » ?
J’aimerais essayer de trouver l’origine du problème.

Regarde la page d’un scénario tu verras tout de suite le mode direct ou non.

Tu veux parler du mode « Synchrone » ?

Oui c’est ça.

J’en ai pas mal, mais ayant une machine puissante, pour moi cela ne posait pas de souci.
Je vais regarder ce que je peux décocher.

Merci pour ton support en tous les cas :+1:

C’est pas la puissance de la machine qui va compter là mais la durée du scénario. En synchrone le scénario ne se lance pas en sous tache. Donc quand jeedom regarde les scénarios à lancer (mode programmé uniquement) il arrive dessus le lance en synchrone et doit donc attendre qu’il finisse avant de passer au scénario suivant. Ça peut donc tout bloquer

En 4.4.8 il y avait la notion de retard en gros jeedom regardait quand le scénario aurait dû tourner et si c’est pas le cas si on était toujours dans une limite acceptable et pouvait le lancer avec jusqu’à 10mib de retard. Mais cela était vraiment très lourd à gérer pour un cas qui ne devrait pas arriver.