Mes tâches automatiques ne s’exécutent plus
Une tâche planifiée n’a personne pour lire son message d’erreur. Elle s’exécute la nuit, sans navigateur, sans utilisateur, et quand elle échoue, rien ne le signale. Le problème se découvre plusieurs jours plus tard, par un flux périmé ou un stock faux. C’est la panne la plus discrète et la plus coûteuse de cette rubrique.
Deux façons très différentes de planifier
Il existe deux mécanismes, souvent confondus. Le premier est une tâche planifiée au niveau du serveur : le système déclenche une commande à heure fixe, indépendamment du trafic. C’est fiable, mais cela demande un accès à l’hébergement pour la créer et la vérifier.
Le second est un déclenchement au passage d’un visiteur : le CMS vérifie à chaque page si une tâche est due, et l’exécute si c’est le cas. C’est simple à mettre en place, mais cela signifie qu’une boutique sans visiteurs n’exécute rien, et qu’une tâche longue est interrompue en même temps que la page qui l’a déclenchée. Une bonne part des « tâches qui ne s’exécutent plus » sont en réalité des tâches de ce second type sur un site à faible trafic nocturne.
Vérifier si elle s’exécute vraiment
-
Chercher la trace de la dernière exécution
Date du fichier généré, dernière ligne du journal, horodatage en base. Sans trace, on ne sait pas si la tâche échoue ou si elle n’est jamais déclenchée : ce sont deux problèmes distincts.
-
Lancer la commande à la main
Si elle fonctionne manuellement mais pas en automatique, le problème est dans la planification, pas dans le traitement. C’est le test qui divise le champ des causes en deux.
-
Vérifier le contexte d’exécution
Une tâche lancée par le serveur n’a ni session ni utilisateur connecté, et parfois une version de PHP différente de celle du site. Un traitement qui suppose un utilisateur échoue silencieusement.
-
Contrôler la durée
Si la tâche met plus longtemps que l’intervalle qui la sépare de la suivante, deux exécutions se chevauchent. Selon le traitement, cela produit des doublons ou un blocage en base.
-
Vérifier les jetons d’accès
Beaucoup de tâches sont déclenchées par une adresse protégée par une clé. Une clé régénérée lors d’une réinstallation invalide toutes les planifications existantes, sans aucun message.
Ce qui casse une planification sans prévenir
- Un changement d’hébergeur : les tâches serveur ne sont pas copiées avec les fichiers et doivent être recréées.
- Un changement de version de PHP : la commande planifiée peut appeler un exécutable qui n’existe plus sous le même nom.
- Un déplacement du site dans un autre répertoire : le chemin absolu inscrit dans la tâche ne mène plus nulle part.
- Un module désinstallé qui emporte ses propres tâches, ou en laisse d’orphelines qui échouent à chaque tentative.
- Un mot de passe ou une clé d’accès à un service externe arrivé à expiration.
Continuer sur la bonne page
-
Tâches cron sur PrestaShop
Le détail du fonctionnement et des pièges propres à PrestaShop.
-
Le cron expliqué
Ce qu’est une tâche planifiée et comment elle est déclenchée.
-
Automatisation
Quand l’enchaînement de traitements mérite d’être repensé plutôt que réparé.
-
Connecter un flux de produits
Si la tâche en panne alimente un comparateur ou une marketplace.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.