Cron - Traitement en tâche de fond du carnet de notes - Erreur de programmation détectée

Cron - Traitement en tâche de fond du carnet de notes - Erreur de programmation détectée

par Christophe Bredelet,
Nombre de réponses : 3

Bonjour,

J'ai actuellement un problème sur une de mes plateformes Moodle.

Informations techniques :
  • Version Moodle précise : 3.7
  • Version PHP : 7.1.30
  • Version base de données : mariadb (10.1.40-MariaDB-cll-lve)
  • Navigateur internet utilisé : Safari 12.1.1
  • Aucun plugin additionnel
Description du problème : 

Quand le Cron se lance, il renvoie l'erreur suivante : 

"Execute scheduled task: Traitement en tâche de fond du carnet de notes (core\task\grade_cron_task)
... started 22:02:13. Current memory use 3.8Mo.
!!! Erreur de programmation détectée. Ceci doit être corrigé par un programmeur : A lock was created but not released at:
[dirroot]/lib/cronlib.php on line 99

 Code should look like:

 $factory = \core\lock\lock_config::get_lock_factory('type');
 $lock = $factory->get_lock(Resource id #63);
 $lock->release();  // Locks must ALWAYS be released like this."

Si je désactive la tâche planifiée "Traitement en tâche de fond du carnet de notes", le cron fini normalement.
Précisions :

C'est une plateforme installée très récemment, en hébergement mutualité chez O2Switch. Le cron a fonctionné normalement tant qu'il n'y avait aucun cours sur la plateforme. 

Puis j'ai restauré hier trois cours, sauvegardés à partir de deux plateforme Moodle : l'une en version 3.6.4, l'autre en version 3.5.2. C'est à ce moment que le cron a fini en erreur sur la plateforme de destination. 

Je pense cela parce que dans les journaux, je ne trouve que des tâches "Traitement en tâche de fond du carnet de notes" en erreur.

La plateforme en 3.5.2 est sur un autre domaine, elle a un plugin additionnel : H5P. Ça vient peut-être de là, mais les cours sauvegardés et restaurés n'utilisent aucune activité H5P, seulement des activités natives.

La plateforme en 3.6.4 est sur le même domaine, il y a 3 plugins additionnels : H5P, Assignment upgrade helper, et Memcache. Ici aussi les cours sauvegardés et restaurés n'utilisent aucune activité H5P, seulement des activités natives.

Un message d'erreur similaire est signalé sur ce post : https://moodle.org/mod/forum/discuss.php?d=386884&mode=1

Les réponses suggèrent de créer une nouvelle base de donnée et d'y importer les données. Ca a l'air lourd, et j'ai l'impression de passer à côté de quelque chose.

Merci d'avance de l'aide que vous pourrez m'apporter.

Christophe BREDELET

Moyenne des évaluations  -
En réponse à Christophe Bredelet

Re: Cron - Traitement en tâche de fond du carnet de notes - Erreur de programmation détectée

par Valery Fremaux,
Avatar Développeurs de plugins
Attention ! voici un faux amis de plus en plus courant dans le cron :

Les textes de ce messages d'erreur ne donnent aucune information sur la vraie cause de l'erreur : en fait, il y a eu une exception avant, qui est la vraie cause du crash du cron. L'erreur de lock n'est qu'une conséquence du crash au moment où le moteur php essaie de déconstruire la pile d'exécution pour sortir. Le problème est que la façon dont moodle a mis en place la surveillance de ces locks préempte l'exception d'origine et la masque dans la trace. Une astuce de développeur est d'aller à cet endroit (le signal d'erreur du lock) et de désactiver le try...catch, afin de laisser sortir l'erreur d'origine.
Heureusement ca n'arrive pas partout dans le cron... ces cas là restent rares, mais arrivent de plus en plus souvent du fait d'un usage de plus en plus assidu des caches et des verrous.
C'est donc très probablement le traitement de cron d'un des plugins (ou un callback d'un des plugins dans un traitement central du coeur moodle) qui produit l'exception initiale... reste à trouver lequel...
V
En réponse à Valery Fremaux

Re: Cron - Traitement en tâche de fond du carnet de notes - Erreur de programmation détectée

par Christophe Bredelet,

Merci pour ce retour.

Je pense avoir pêché par excès de confiance, car la documentation « Migration de Moodle » signale explicitement un risque de casse des liens absolus dans la section « restaurer un seul espace entre deux serveurs ». Je l’ai ignoré parce que j’ai (trop) tendance à fonctionner par essai erreur.

Toutefois ce qui me surprend, et c’est la raison pour laquelle j’ai posté cet incident, c’est la teneur du message, qui me fait penser que je me trompe peut-être sur son origine, et aussi le fait que même après avoir supprimé tous les cours de la nouvelle plateforme, le cron continue à planter sur la tâche « traitement du carnet de notes », alors qu’il fonctionne quand je déplanifie cette tâche. Ca m’intrigue.

Heureusement ce sont de petites bases de données (à peine une quinzaine d’inscrits par cours, et moins d’une dizaine d’activités au total), et j’installe à partir de Softaculous. Je vais attendre un peu si quelqu’un a une idée, et sinon je vais repartir de zéro.

Christophe


En réponse à Valery Fremaux

Re: Cron - Traitement en tâche de fond du carnet de notes - Erreur de programmation détectée

par Christophe Bredelet,
Bonjour Valery,
N'ayant pas une culture de développeur, j'avoue qu'il me faudra plusieurs relectures avant de pouvoir exploiter votre conseil, en particulier l'expression "la façon dont moodle a mis en place la surveillance de ces locks préempte l'exception d'origine et la masque dans la trace", qui est particulièrement dense 🙂 !

Cela dit J'en retiens aujourd'hui que la manip consistant à sauvegarder / restaurer un cours d'une plateforme à une autre n'est pas du tout une opération anodine. En particulier lorsqu'il y a côté source des plugins tiers. Dans mon cas, seul H5P avait été installé délibérément, et les cours sauvegardés ne contenaient pas d'activités H5P. Pour les deux autres plugins tiers, je ne me souviens pas d'avoir installé Assignment Upgrade Helper. Je suppose qu'il a été généré lors d'une mise à jour, puisque c'est un composant qui a été retiré du noyau en 3.6. Peut-être la même chose pour Memcache.

Je n'ai pas su remettre sur pied le cron de ma plateforme de destination. Voici la procédure que j'ai suivi:
  • J'ai refais une sauvegarde de mes trois cours à partir de la plateforme de destination, car en 3.7, et vierge de tout plugin tiers.
  • Dans ces archives de sauvegarde, j'ai vérifié que le fichier moodle_backup.xml ne contenait pas de liens absolus vers un autre serveur.
  • J'ai supprimé ma plateforme de destination pour refaire une installation vierge (via softaculous).
  • J'ai ensuite reparamètré cette installation selon mon cahier des charges perso (RGPD, règles de sécurité...)
  • Puis j'ai restauré les cours précédemment sauvegardés.
Le journal des tâches programmées ne signale à présent aucune erreur, et le cron fonctionne.

Merci pour votre aide.
Ch. BREDELET