La tâche cron ne fonctionne pas : causes et solutions

Une tâche cron est configurée dans cPanel, mais la tâche attendue ne s'exécute pas ? Vous devez alors vérifier séparément le calendrier, la commande et le script appelé.

Une erreur particulièrement fréquente lors du diagnostic consiste à assimiler automatiquement un cronjob qui ne fonctionne pas à un calendrier défectueux. En réalité, cPanel peut lancer correctement le cronjob, alors que c'est seulement la commande exécutée ou le script appelé qui échoue.

Dans ce guide, nous vous montrons comment analyser systématiquement un cronjob qui ne fonctionne pas et identifier les erreurs typiques concernant le calendrier, les chemins, la version de PHP, les permissions, les sorties et WordPress WP-Cron.

Règle de base : Vérifie d'abord si la tâche cron est lancée. Vérifie ensuite si la commande enregistrée fonctionne. Ce n'est qu'après que tu examines l'application elle-même. Tu évites ainsi de faire des modifications sur plusieurs niveaux techniques en même temps.

Les trois niveaux d'un problème de cronjob #

Pour un dépannage efficace, vous devez distinguer trois domaines :

1. Calendrier
   ↓
Le cronjob est-il exécuté à l'heure prévue ?

2. Commande
   ↓
La commande saisie peut-elle être exécutée ?

3. Application
   ↓
Le script appelé fonctionne-t-il correctement lui-même ?

Cette distinction est cruciale.

Un cronjob peut par exemple être lancé à l'heure prévue, mais s'interrompre immédiatement en raison d'un chemin de fichier erroné. De même, PHP peut démarrer correctement, tandis que le script PHP lui-même génère une erreur fatale.

1. Vérifier la tâche cron dans cPanel #

Connecte-toi à ton cPanel CURIAWEB et ouvre :

Options avancées → Tâches Cron

Vérifiez d'abord si le cronjob en question figure effectivement dans la liste des cronjobs existants.

Vérifiez ensuite l'entrée complète, en particulier le calendrier et la commande.

Si vous ne savez toujours pas comment configurer correctement une tâche cron, vous trouverez les bases sur Créer une tâche cron dans cPanel et configurer correctement le calendrier.

2. Vérifier le calendrier avec précision #

Un calendrier cron se compose de cinq champs :

Minute, heure, jour, mois, jour de la semaine

Un cronjob quotidien à 03h00 peut par exemple ressembler à ceci :

0 3 * * *

Un travail cron toutes les cinq minutes :

*/5 * * * *

Vérifiez les valeurs caractère par caractère.

Minute et heure confondues #

Une erreur fréquente est la confusion des deux premiers champs.

Par exemple :

30 3 * * *

signifie en principe tous les jours à 03h30.

L'ordre n'est pas l'heure et la minute, mais :

Minute → Heure

Ne pas confondre le jour du mois et le jour de la semaine #

Ces deux champs ont également des significations différentes.

Par exemple :

0 6 * * 1

correspond par principe à une exécution le lundi à 06h00.

En revanche :

0 6 1 * *

signifie généralement une exécution le premier jour d'un mois à 06:00.

3. Prendre en compte l'heure du serveur ou le fuseau horaire #

Si le travail cron fonctionne mais semble s'exécuter à la mauvaise heure, vous devriez vérifier le fuseau horaire pertinent pour l'exécution de cron.

L'heure locale de votre ordinateur et celle utilisée par le serveur ne doivent pas nécessairement être identiques.

Conseil pratique : Si une tâche cron s'exécute de manière fiable mais diffère toujours d'une ou deux heures de l'heure prévue, le fuseau horaire est l'un des premiers points que vous devez vérifier.

Tenir compte de l'heure d'été et d'hiver #

Pour les tâches qui doivent impérativement s'exécuter à une heure locale précise, le passage à l'heure d'été ou d'hiver peut également être pertinent.

Ne modifiez donc pas immédiatement un planning par ailleurs fonctionnel sur de simples suppositions si le temps d'exécution observé a changé.

4. Contrôler la commande cron complète #

Si le calendrier est correct, vérifie la commande proprement dite.

Un cronjob PHP peut par exemple être structuré schématiquement de cette manière :

/pfad/zur/php-binary /home/CPANELUSER/public_html/script.php

Un seul caractère erroné, un répertoire inexistant ou un mauvais binaire PHP peut empêcher la commande de fonctionner.

Important : N'utilisez pas simplement une commande cron tirée du guide d'un autre hébergeur. Les chemins PHP et les structures de répertoires peuvent différer.

5. Vérifier les chemins absolus #

Les tâches cron doivent de préférence utiliser des chemins absoluts explicites.

Un chemin de fichier peut se présenter schématiquement ainsi :

/home/CPANELUSER/public_html/script.php

Une entrée telle que :

script.php

est en revanche un chemin relatif et suppose que le répertoire de travail approprié est utilisé.

C'est précisément cette hypothèse qui peut être fausse lors d'une exécution automatique par cron.

Mauvaise racine de document #

Sur un compte d'hébergement avec plusieurs domaines, un site Web ne doit pas nécessairement se trouver sous public_html se trouver.

Un domaine ou un sous-domaine supplémentaire peut par exemple posséder sa propre racine de document.

Si le cronjob appelle un fichier du mauvais site Web ou d'un mauvais répertoire, la commande peut échouer ou même cibler une autre installation.

Vous pouvez consulter la structure des répertoires avec Gestionnaire de fichiers cPanel contrôler.

6. Vérifier si le fichier existe effectivement #

Ouvrez le répertoire spécifié dans la tâche cron dans le gestionnaire de fichiers cPanel.

Vérifie :

• Le fichier existe-t-il ?
• Le nom du fichier est-il exact ?
• La casse est-elle correcte ?
• Le fichier se trouve-t-il dans le répertoire spécifié ?

Les systèmes de fichiers Linux font fondamentalement une distinction entre les majuscules et les minuscules.

Par exemple, les éléments suivants peuvent :

cron.php

être des noms de fichiers différents.

7. Résoudre l'erreur „ No such file or directory “ #

Un message tel que :

Aucun fichier ou dossier de ce nom

indique souvent qu'un fichier ou un programme spécifié n'a pas été trouvé sous le chemin utilisé.

Vérifie ensuite en particulier :

• Chemin d'accès au binaire PHP
• Chemin du script
• Nom de fichier
• Racine du document
• si le fichier a été déplacé après une migration

8. Résoudre l'erreur „ Commande introuvable “ #

Un message tel que :

commande introuvable

signifie généralement que la commande appelée n'a pas pu être trouvée.

Cela peut par exemple se produire si un cronjob se contente de :

php script.php

utilisé et en s'en remettant au fait que le PHP souhaité soit automatiquement trouvé via le chemin de recherche.

Avec les tâches cron, il est plus fiable d'utiliser l'exécutable réellement requis ou la commande complète prévue par l'application.

9. Vérifier le binaire PHP #

Pour les tâches cron PHP, il faut déterminer quelle version de PHP doit exécuter le script.

La version PHP d'un site Web et la version PHP d'une commande en ligne ne sont pas automatiquement identiques.

Par exemple, si votre site Web fonctionne avec une version spécifique de PHP, mais que la tâche cron utilise un autre binaire PHP, le script peut générer des erreurs lors de son exécution automatique.

Vous gérez fondamentalement la version PHP d'un domaine sur CURIAWEB via le MultiPHP-Manager.

Important : Le gestionnaire MultiPHP détermine la configuration PHP Web du domaine. Dans le cas d'une tâche cron CLI, il faut tout de même vérifier séparément quel binaire PHP est appelé dans la commande cron.

10. Ne pas deviner la version PHP de la tâche cron avec php -v #

Un appel général tel que :

php -v

affiche la version PHP de la commande CLI ainsi résolue.

Cela ne prouve pas automatiquement que :

• le site Web utilise la même version de PHP
• le cronjob utilise le même binaire PHP
• les extensions PHP requises sont identiques

Ce qui est déterminant, c'est la commande effectivement utilisée dans le cronjob.

11. Vérifier les extensions PHP manquantes #

Un script PHP peut être correctement installé et néanmoins échouer si l'environnement PHP utilisé ne fournit pas une extension requise.

Les messages d'erreur typiques peuvent indiquer des classes ou des fonctions inexistantes.

Vérifiez ensuite d'abord quelle version de PHP ou quel environnement PHP le travail cron utilise réellement.

Tu trouveras plus d'informations sur Activer et gérer les extensions PHP dans cPanel.

12. Tenir compte des différentes configurations PHP #

Un script PHP peut fonctionner via le site Web et présenter malgré tout un comportement différent via une tâche cron CLI.

La raison peut être que Web-PHP et CLI-PHP utilisent des configurations différentes.

Cela peut inclure, par exemple, des différences dans :

Version PHP
Extensions PHP
memory_limit
Fichiers de configuration
Variables d'environnement

appartenir.

Par conséquent, ne transférez pas automatiquement chaque paramètre PHP Web vers une tâche cron CLI.

13. Correction de l'erreur „ Permission denied “ #

Un message tel que :

Accès refusé

indique un problème d'autorisation.

La cause exacte dépend de ce qui doit être exécuté ou ouvert.

Vérifie en particulier :

• Autorisations de fichiers
• Autorisations de répertoire
• que le script soit exécuté directement ou appelé via un interpréteur
• si le script doit écrire ou modifier des fichiers

Vous trouverez les bases à ce sujet sous Définir correctement les autorisations de fichiers 644 et 755 dans cPanel.

Attention : Ne définissez pas les autorisations de fichiers de manière globale sur 777, pour contourner une erreur. Cela ne résout pas proprement la cause profonde et la configuration peut devenir inutilement non sécurisée.

14. Vérifier si le script a besoin de droits d'écriture #

Un tâche cron peut lancer le script PHP avec succès, tandis que le script lui-même échoue lors de l'écriture d'un fichier.

Cela concerne par exemple les processus qui :

• Générer des fichiers de cache
• Enregistrer l'exportation
• Déplacer les fichiers d'importation
• Écrire des fichiers journaux
• créer des fichiers temporaires

Vérifiez ensuite les autorisations du répertoire cible spécifique.

15. Ne pas rejeter immédiatement la sortie de cron #

Lors du dépannage, la sortie du travail cron est l'une des sources d'information les plus importantes.

Par exemple, si votre commande commence par :

> /dev/null 2>&1

se terminent, la sortie standard et la sortie d'erreur sont ignorées.

C'est problématique avec un travail cron défectueux.

Conseil pratique : Pendant le diagnostic, désactivez temporairement toute suppression de sortie configurée intentionnellement, si cela est pertinent et sûr pour la commande concernée. Vous pourrez ainsi voir le message d'erreur réel.

Distinguer la sortie standard et la sortie d'erreur #

Les commandes Linux peuvent fondamentalement utiliser deux canaux de sortie pertinents :

stdout
→ sortie normale

stderr
→ messages d'erreur

Si seule la sortie normale est redirigée, un message d'erreur peut toujours apparaître ailleurs.

L'orthographe :

2>&1

redirige la sortie d'erreur vers la même destination que la sortie standard.

17. Enregistrer temporairement la sortie de cron #

Pour un script personnel, il peut être utile pour le diagnostic d'écrire temporairement des sorties dans un fichier journal.

Schématiquement :

COMMANDE >> /home/CPANELUSER/logs/cron-test.log 2>&1

Cela permet d'ajouter la sortie standard et les messages d'erreur à un fichier.

Utilisez un chemin existant et accessible en écriture.

Important : Un tel fichier de journal de diagnostic doit être vérifié et, après le dépannage, supprimé ou géré de manière judicieuse. Des tâches cron exécutées fréquemment peuvent faire croître rapidement les fichiers journaux.

18. Vérifier les e-mails sortants de la tâche cron #

cPanel peut envoyer les sorties des tâches cron à une adresse e-mail configurée.

Si tu utilises cette fonction, vérifie également le dossier spam de la boîte aux lettres concernée.

Un e-mail cron peut par exemple contenir un message d'erreur qui indique directement un chemin erroné ou une erreur PHP.

19. Exécuter la tâche cron manuellement #

Si vous disposez d'un accès SSH et que la commande peut être exécutée manuellement sans danger, un test manuel est très utile.

Exécutez pour cela le plus précisément possible la commande qui est également enregistrée dans la tâche cron.

Cela vous permet de distinguer deux cas :

Le commande ne fonctionne pas manuellement
→ Le problème vient probablement de la commande ou du script

La commande fonctionne manuellement
→ Examiner de plus près l'environnement cron ou le planning

Attention : N'exécutez pas une importation, un processus d'expédition, un processus de paiement ou toute autre tâche modificative plusieurs fois à titre de test si vous ne connaissez pas leur comportement en cas de répétition.

Fonctionne manuellement - pas en tant que cronjob #

Si la même commande fonctionne dans un shell interactif mais pas en tant que tâche cron, vous devriez examiner en particulier l'environnement d'exécution.

Les tâches cron ne possèdent peut-être pas les mêmes variables d'environnement que votre session SSH interactive.

Sont pertinents, par exemple :

• Chemin
• Répertoire de travail
• PHP-Binary
• autres variables d'environnement

Utilisez par conséquent des chemins d'accès aussi complets que possible vers les programmes et les fichiers.

21. Vérifier le répertoire de travail du script #

Certains scripts utilisent en interne des chemins de fichiers relatifs.

Par exemple :

include 'config.php';

ou ils attendent des fichiers par rapport au répertoire de travail actuel.

Si le script est lancé dans un autre environnement, cela peut entraîner des problèmes.

Une application robuste doit traiter les chemins requis de manière univoque. Pour une application tierce, vous devez utiliser l'instruction cron prévue à cet effet.

22. L'appel HTTP fonctionne, l'appel CLI ne fonctionne pas #

Certaines applications fournissent une URL pour les tâches cron.

Un appel HTTP et un appel direct en CLI PHP ne sont pas techniquement identiques.

HTTP :
Cron → HTTP/HTTPS → Serveur Web → Application

CLI :
Cron → Binaire PHP → Script PHP

Si le fabricant prévoit expressément un appel HTTP, vous ne devez pas le remplacer par un appel PHP direct sans raison technique.

23. L'interface en ligne de commande (CLI) fonctionne, mais pas l'appel HTTP #

Inversement, un appel PHP direct peut fonctionner, tandis qu'un appel HTTP échoue.

Lors d'un appel HTTP, des composants supplémentaires s'ajoutent :

• DNS
• Serveur Web
• HTTPS
• Redirections
• Protection contre l'accès non autorisé
• Routage d'applications

Vérifiez par conséquent quel mode d'appel l'application prévoit réellement.

24. Le cronjob HTTP reçoit une erreur 403 Forbidden #

Lorsqu'un travail cron appelle une URL et envoie

403 Interdit

reçoit, l'appel HTTP atteint fondamentalement le serveur web, mais il n'est pas autorisé comme prévu.

La cause peut par exemple résider dans le contrôle d'accès, les règles de sécurité ou l'application.

Nous traitons le diagnostic systématique sous Résoudre l'erreur 403 Forbidden.

25. Le cronjob HTTP reçoit une erreur 500 Internal Server Error #

Un

500 Erreur interne du serveur

indique une erreur côté serveur lors du traitement.

Dans ce cas, il est tout à fait possible que la tâche cron ait été lancée correctement. L'erreur ne se produit qu'au moment de l'appel HTTP ou au sein de l'application.

Vous trouverez de plus amples informations sur Résoudre l'erreur interne du serveur 500.

26. Examiner l'erreur fatale PHP #

Si la sortie contient une erreur fatale PHP, le planning n'est généralement pas le problème principal.

Le message d'erreur PHP concret est alors déterminant.

Les causes possibles sont par exemple :

• Version PHP incompatible
• extension PHP manquante
• code d'application défectueux
• fichier manquant
• Problème de mémoire

Ne modifiez pas plusieurs paramètres PHP en même temps, mais travaillez en vous basant sur le message d'erreur concret.

27. „ Taille de mémoire autorisée épuisée “ #

Un message tel que :

Taille de mémoire autorisée ... épuisée

indique que le processus PHP a atteint sa limite de mémoire disponible.

Vérifiez impérativement quel environnement PHP exécute la tâche cron.

Les paramètres PHP Web d'un domaine ne s'appliquent pas nécessairement automatiquement à un processus PHP CLI.

Vous trouverez les bases concernant les limites PHP sur Définir la limite de mémoire PHP, la taille de téléchargement et le temps d'exécution.

28. Bien classer la durée d'exécution et les délais d'attente #

Si une tâche cron s'arrête lors d'une tâche plus longue, la durée d'exécution peut jouer un rôle.

Faites la distinction entre :

• Limites de l'environnement PHP utilisé
• Limites ou comportement de l'application
• services externes
• Ressources d'hébergement

Un processus CLI ne se comporte pas nécessairement de la même manière qu'un appel de page web classique en ce qui concerne les limites PHP.

29. L'API externe ne répond pas #

Un cronjob peut fonctionner techniquement de manière correcte et malgré tout ne pas achever sa tâche si le script dépend d'un service externe.

Les exemples sont :

• APIs externes
• Systèmes de gestion des stocks
• Systèmes CRM
• Services de paiement
• sources de données externes

Vérifiez dans ce cas la sortie ou le journal des applications pour détecter des erreurs de connexion, des problèmes d'authentification ou des dépassements de délai.

30. Vérifier les identifiants de connexion ou les clés API #

Lorsqu'un travail cron échange des données avec un système externe, des identifiants invalides ou expirés peuvent en être la cause.

Voici quelques erreurs courantes :

Non autorisé
Échec de l'authentification
Clé API invalide
Accès refusé

Ne stockez pas directement dans la commande cron des identifiants sensibles sans les protéger.

31. Le cronjob s'exécute trop souvent #

Un cronjob peut fonctionner techniquement et pourtant causer des problèmes s'il est lancé trop souvent.

Exemple :

Départ toutes les 5 minutes
Durée : 12 minutes

Une nouvelle instance peut alors être lancée pendant que la précédente est toujours en cours d'exécution.

32. Détecter les processus qui se chevauchent #

L'exécution simultanée de plusieurs instances peut, par exemple, entraîner les problèmes suivants :

• double traitement
• fichiers verrouillés
• Conflits de base de données
• augmentation de l'utilisation du processeur
• d'une plus grande consommation de mémoire
• limites d'API externes

Pour les tâches de longue durée, vérifie donc si l'intervalle correspond à la durée d'exécution réelle.

33. Protéger l'application contre l'exécution parallèle #

Les applications professionnelles utilisent, pour certaines tâches, des mécanismes susceptibles d'empêcher l'exécution parallèle.

Cela peut se faire par exemple via des fichiers de verrouillage, l'état de la base de données ou d'autres mécanismes de verrouillage.

N'implémentez pas de tels mécanismes par simple suspicion dans des applications tierces. Consultez d'abord leur documentation.

34. Contrôler les ressources d'hébergement #

Une tâche cron peut mobiliser des ressources du processeur, de la mémoire vive, des processus et de la base de données.

Dans le cas de tâches fréquentes ou de grande envergure, l'utilisation des ressources peut donc être un facteur important.

Nous t'expliquons comment vérifier les valeurs de CloudLinux à la rubrique Comprendre l'utilisation des ressources CloudLinux dans cPanel.

35. La limite des ressources est atteinte #

Si votre site web ou votre application montre simultanément des indices de ressources d'hébergement épuisées, cela devrait être examiné séparément.

Une tâche cron peut provoquer un pic de charge ou coïncider avec une charge déjà élevée.

Nous traitons le diagnostic ciblé sous Limite de ressources atteinte : identifier et corriger les limites CloudLinux.

36. Lancer plusieurs tâches cron simultanément #

Si plusieurs tâches Cron gourmandes en ressources démarrent exactement à la même minute, cela peut entraîner un pic de charge inutile.

Par exemple :

03h00 → Importation
03h00 → Exportation
03h00 → Synchronisation
03h00 → Traitement des statistiques

Si les horaires des applications sont flexibles, il peut être plus judicieux de prévoir des heures de début différentes.

Ne modifiez toutefois pas les intervalles prédéfinis d'une application sans les avoir vérifiés au préalable.

37. Le cronjob ne fonctionne plus après le déplacement du site web #

Après un changement d'hébergeur ou une migration de site web, les tâches Cron font partie des paramètres qui doivent être vérifiés séparément.

Les chemins d'accès absolus, en particulier, peuvent avoir changé.

Une ancienne tâche cron peut, par exemple, continuer à s'exécuter sur :

/home/ALTERUSER/...

montrer, bien que l'application se trouve désormais sous un autre chemin de compte.

38. Vérifier la tâche cron après le changement de domaine #

Lorsque le cronjob appelle une URL, un changement de domaine peut également être pertinent.

Vérifiez ensuite :

• Nom d'hôte
• HTTPS
• Redirections
• Chemin de l'URL Cron
• Protection contre l'accès non autorisé

Un ancien travail cron HTTP peut sinon continuer à appeler une adresse qui n'est plus valide.

39. La tâche cron ne fonctionne plus après le changement de version de PHP #

Si le problème survient immédiatement après un changement de version PHP, tu devrais vérifier quel binaire PHP le travail cron utilise.

Un chemin CLI codé en dur n'est pas nécessairement mis à jour automatiquement lors du changement de version PHP du Web.

Vérifiez également si l'application et les extensions requises sont compatibles avec la version de PHP utilisée.

40. La tâche cron ne fonctionne plus après la mise à jour #

Si une application ne traite plus correctement sa tâche cron immédiatement après une mise à jour, notez :

• quelle application a été mise à jour
• quelle version a été utilisée auparavant
• quelle version est utilisée actuellement
• quel message d'erreur le cronjob génère

Vérifiez ensuite la documentation ou les exigences système de l'application.

Ne modifiez pas simultanément la syntaxe Cron, la version de PHP et les permissions de fichiers si l'erreur n'a clairement commencé qu'après une mise à jour logicielle.

41. WordPress WP-Cron ne fonctionne pas #

WordPress utilise par défaut WP-Cron pour les tâches planifiées.

WP-Cron n'est pas un cronjob Linux classique. Par défaut, les tâches planifiées sont déclenchées lors des visites sur le site Web.

Par conséquent, si les tâches WordPress sont exécutées en retard ou pas du tout, vous devez d'abord vérifier si :

• le WP-Cron normal est utilisé
• WP-Cron a été délibérément désactivé
• un véritable cron serveur a été configuré en remplacement
• ce serveur cron fonctionne réellement

Vérifier DISABLE_WP_CRON #

Dans le fichier WordPress wp-config.php il peut y avoir, par exemple, le paramètre suivant :

define( 'DISABLE_WP_CRON', true );

Cela désactive le mécanisme d'appel WordPress normal pour WP-Cron.

Cela n'a de sens que si un autre mécanisme fiable a été consciemment mis en place pour les tâches WordPress prévues.

Attention : Supprimer ou modifier DISABLE_WP_CRON ne fais pas aveuglément. Vérifie d'abord pourquoi le paramètre a été défini et si une tâche cron serveur existe en remplacement.

43. Cron serveur pour WordPress présent, les tâches ne s'exécutent toujours pas #

Si un véritable travail cron doit déclencher WordPress régulièrement, vérifiez d'abord si ce travail cron lui-même s'exécute avec succès.

Ensuite, il faut vérifier si WordPress traite effectivement les tâches en retard.

Avec cela, tu sépares à nouveau :

Le serveur cron fonctionne ?
        ↓
WordPress est atteint ?
        ↓
WP-Cron traite les tâches en attente ?
        ↓
Chaque application traite sa tâche ?

44. La tâche WooCommerce ne s'exécute pas #

WooCommerce et ses extensions peuvent utiliser des tâches d'arrière-plan planifiées.

Si une tâche spécifique de la boutique ne s'exécute pas, cela ne signifie pas automatiquement que la tâche cron cPanel est défectueuse.

Vérifiez d'abord à quel niveau la tâche en question est planifiée et traitée.

Dans le cas des systèmes WordPress/WooCommerce, le système interne des tâches planifiées peut également jouer un rôle.

45. Une tâche cron envoie un grand nombre d'e-mails #

Lorsque qu'un travail cron déclenche des e-mails, tu dois être particulièrement prudent lors des tests.

Une tâche cron de test configurée pour s'exécuter chaque minute peut sinon déclencher à nouveau la même fonction d'envoi.

Attention : N'utilisez pas d'intervalle de test agressif pour les processus d'expédition, de newsletter, de facturation ou de notification tant que vous ne savez pas comment l'application empêche les exécutions multiples.

46. Le cronjob génère des doublons de données #

Des doublons peuvent indiquer que :

• le cronjob a été configuré plusieurs fois
• exécuter plusieurs processus identiques en parallèle
• l'application elle-même ne possède aucune protection contre le double traitement
• qu'un cron serveur et un autre planificateur déclenchent la même tâche

Vérifie d'abord la liste des cronjobs existants, puis la configuration de l'application.

47. Vérifier si le même travail cron est présent en double #

Vérifiez sur :

Options avancées → Tâches Cron

qu'une commande identique ou presque identique ait été entrée plusieurs fois.

Cela peut se produire, par exemple, après une migration ou une nouvelle configuration manuelle.

Ne supprimez une entrée que si vous savez avec certitude qu'il s'agit bien d'un doublon inutile.

Le cronjob a été supprimé #

Si une application cesse soudainement de traiter des tâches planifiées, vérifiez également si le travail cron requis est toujours présent.

Cela peut par exemple être pertinent après un nettoyage, une migration ou une modification manuelle.

Un cronjob supprimé n'est pas automatiquement restauré du fait que l'application est toujours installée.

49. Anciens crontobs après la désinstallation d'une application #

À l'inverse, des tâches cron peuvent subsister bien que l'application associée n'existe plus.

Ensuite, la tâche cron peut appeler régulièrement un chemin qui n'existe plus et générer continuellement des messages d'erreur.

Vérifiez donc également lors de la suppression d'une application si les cronjobs associés sont toujours nécessaires.

50. Ne pas réparer une tâche cron par des essais permanents #

Si une tâche cron ne fonctionne pas, vous ne devriez pas en même temps :

Modifier le planning
Modifier la version PHP
Modifier les permissions des fichiers
Déplacer le script
Modifier les limites PHP
Remplacer la commande cron

Ensuite, il est presque impossible de déterminer quel changement a réellement été pertinent.

Travaillez plutôt du cronjob vers l'application :

Planning
→ Commande
→ Chemins
→ Environnement d'exécution
→ Message d'erreur
→ Application

Bien classer les messages d'erreur typiques #

Message d'erreur / Problème	Vérifier d'abord
commande introuvable	Commande et chemin complet vers le fichier exécutable
Aucun fichier ou dossier de ce nom	Chemin de fichier, nom de fichier et racine du document
Accès refusé	Droits de fichiers/répertoires et mode d'exécution
Erreur fatale PHP	message PHP concret, version de PHP et application
Taille de mémoire autorisée épuisée	Environnement PHP et besoins en mémoire
Le cronjob s'exécute à la mauvaise heure	Calendrier et fuseau horaire
Manuel fonctionne, pas cron	chemins absolus et environnement cron
L'appel HTTP renvoie 403	Contrôle d'accès, règles de sécurité et application
L'appel HTTP renvoie 500	Erreurs de serveur, de PHP et d'application et journaux
La tâche est exécutée deux fois	tâches cron en double et processus qui se chevauchent
Après le déménagement, Cron ne fonctionne pas	chemins absolus et domaine
Le cron ne fonctionne plus après le changement de PHP	Binaire PHP et extensions requises

Diagnostic systématique en dix étapes #

1. Ouvrir Options avancées → Tâches Cron et vérifie si la tâche cron est présente.
2. Vérifiez la minute, l'heure, le jour, le mois et le jour de la semaine.
3. Prenez en compte le fuseau horaire applicable à l'exécution.
4. Vérifiez la commande complète.
5. Vérifiez tous les chemins absolus de fichiers et de programmes.
6. Vérifiez le binaire PHP utilisé pour les scripts PHP.
7. Supprimez la suppression de sortie éventuellement configurée intentionnellement pour le diagnostic.
8. Notez le message d'erreur complet.
9. Testez la commande – si cela est possible sans danger – manuellement.
10. Examine ensuite l'application elle-même.

S'il n'y a pas de message d'erreur #

Si vous ne recevez aucune sortie, vous devez d'abord vérifier si elle est délibérément supprimée.

Recherchez dans la commande cron par exemple :

/dev/null

Vérifiez également si les sorties des tâches Cron sont envoyées par e-mail et si l'application possède son propre fichier journal.

Dans le cas d'un script personnel, une journalisation contrôlée temporaire peut être utile.

Si le cronjob fonctionne de manière sporadique #

Une tâche cron qui n'échoue pas toujours nécessite une approche différente d'une commande fondamentalement erronée.

En cas de problèmes sporadiques, vérifiez en particulier :

• Utilisation des ressources
• durée
• processus qui se chevauchent
• APIs externes
• Dépendances réseau
• données d'entrée changeantes
• Journaux d'application au moment précis de l'erreur

Notez si possible l'heure exacte d'une erreur. Cela permet d'associer beaucoup plus facilement les journaux et les valeurs de ressources.

Interpréter correctement le journal des erreurs cPanel #

En cas d'erreurs d'une.

Nous expliquons l'évaluation sous Lire le journal des erreurs cPanel et trouver les erreurs du site Web.

Cependant, un tâche cron exécutée directement via PHP-CLI ne doit pas nécessairement consigner ses erreurs dans le même journal du serveur web. C'est pourquoi vous devez également vérifier la sortie cron et les journaux de l'application.

Quand devez-vous contacter le support CURIAWEB ? #

Si tu as vérifié le calendrier, la commande, les chemins et les sorties, mais que la tâche cron ne fonctionne toujours pas comme prévu, documente le problème de la manière la plus concrète possible.

Pour une analyse technique, les informations suivantes sont particulièrement utiles :

• domaine ou application concerné
• calendrier Cron configuré
• commande cron complète sans données confidentielles
• comportement attendu
• comportement réel
• heure approximative ou exacte de la dernière exécution ayant échoué
• message d'erreur complet
• binaire PHP ou version de PHP utilisée, si pertinent
• si la commande identique fonctionne manuellement
• si le cronjob fonctionnait auparavant
• quel changement a été apporté immédiatement avant le problème

Consigne de sécurité : Supprimez les mots de passe, clés API, jetons et autres identifiants de la commande cron avant de la transmettre. Ne transmettez pas inutilement de telles informations confidentielles.

Résumé #

Si un cronjob ne fonctionne pas, vous devez d'abord déterminer à quel niveau le problème survient. Un cronjob ne se résume pas à son calendrier : cPanel lance une commande qui, à son tour, exécute un script ou une autre application.

Vérifiez par conséquent d'abord le planning Cron et le fuseau horaire. Vérifiez ensuite la commande complète, les chemins absolus et, pour les scripts PHP, le binaire PHP effectivement utilisé.

Des messages tels que commande introuvable, Aucun fichier ou dossier de ce nom ou Accès refusé fournissent déjà des indices importants sur la cause. Les erreurs fatales PHP doivent en revanche être analysées à l'aide du message PHP concret.

Ne supprimez pas prématurément les messages d'erreur lors du diagnostic avec /dev/null. Les sorties de cron, les fichiers journaux et un test manuel contrôlé sont souvent les moyens les plus rapides de trouver la cause.

Si une commande fonctionne manuellement mais pas en tant que tâche cron, vous devez prêter une attention particulière aux chemins absoluts, au binaire PHP, au répertoire de travail et aux variables d'environnement.

Sous WordPress, il faut en outre faire la distinction entre le WP-Cron propre à WordPress et un véritable travail cron (cronjob) du serveur. Est DISABLE_WP_CRON activé, il doit y avoir un mécanisme alternatif fonctionnel.

En cas d'erreurs sporadiques, vous devez également examiner la consommation de ressources, les processus qui se chevauchent et les dépendances externes.

La règle la plus importante pour un dépannage efficace est : Ne tout pas modifier en même temps. Vérifie le calendrier → la commande → les chemins → l'environnement d'exécution → le message d'erreur → l'application dans cet ordre exact.