Créer une tâche cron dans cPanel et configurer correctement le calendrier

Avec un Tâche cron vous pouvez faire exécuter automatiquement par votre hébergement web certaines commandes ou certains scripts à des heures fixes. Les tâches cron conviennent par exemple pour les tâches de maintenance régulières, les importations, les exportations, le traitement de données ou les scripts PHP planifiés.

Dans CURIAWEB-cPanel, vous pouvez créer et gérer des tâches cron directement via l'interface utilisateur. Deux informations y sont particulièrement importantes : Quand le cronjob doit-il être exécuté et quelle commande doit être exécutée ?

Dans ce guide, nous vous montrons comment créer une tâche cron dans cPanel, configurer correctement les heures, utiliser des chemins absolus et éviter les erreurs courantes.

Important : Un travail cron exécute automatiquement la commande enregistrée. Par conséquent, vérifiez soigneusement ce que fait la commande, en particulier pour les scripts, les importations, les fonctions de suppression ou de maintenance, avant de la laisser s'exécuter régulièrement.

Qu'est-ce qu'un cronjob ? #

Un cronjob est une tâche planifiée sur un système Linux.

Pour faire simple, un cronjob se compose de :

Calendrier
+
Commande
=
tâche exécutée automatiquement

Vous pouvez par exemple définir :

Tous les jours à 03:00
→ Exécuter le script PHP

ou

Toutes les 15 minutes
→ lancer un processus spécifique

Ensuite, le serveur se charge de l'exécution automatiquement, sans que vous ayez à vous connecter à cPanel à chaque fois.

À quoi servent les tâches cron ? #

Les tâches cron sont utilisées par les applications Web et les scripts personnalisés pour diverses tâches récurrentes.

Des exemples typiques sont :

• importations de données régulières
• exportations automatiques
• Traitement des files d'attente
• tâches de maintenance planifiées
• Appel de scripts PHP personnels
• Synchronisation des données
• Exécution des tâches d'un CMS ou d'une boutique

Les tâches cron nécessaires dépendent de l'application utilisée.

Ne pas créer de tâche Cron sans spécifier d'application #

Si une documentation logicielle exige une tâche cron spécifique, vous devez utiliser la commande qui y est indiquée et l'intervalle recommandé comme point de départ.

N'inventez pas vous-même de commande d'exécution si vous ne savez pas comment l'application traite ses tâches planifiées.

Conseil pratique : De nombreuses applications Web fournissent déjà dans leur documentation une commande cron complète ou au moins le script à exécuter et un intervalle recommandé.

1. Se connecter à cPanel #

Connectez-vous à votre cPanel CURIAWEB.

Ouvrez ensuite :

Options avancées → Tâches Cron

Vous y trouverez les cronjobs existants et pourrez créer de nouvelles tâches.

Vérifier l'adresse e-mail pour les sorties de tâches cron #

Dans la section des tâches Cron, cPanel peut proposer un paramètre pour les notifications par e-mail ou les sorties de Cron.

Si un travail cron produit une sortie, celle-ci peut – selon la configuration – être envoyée par e-mail.

Cela peut s'avérer très utile lors de l'installation et du dépannage.

Important : Ne supprimez pas immédiatement la sortie d'une nouvelle tâche cron. En particulier lors du premier test, les messages d'erreur peuvent fournir des indices importants si la commande ne fonctionne pas correctement.

3. Ajouter une nouvelle tâche cron #

Accédez à la section d'ajout d'une nouvelle tâche cron.

Un cronjob nécessite fondamentalement :

• Minute
• Heure
• Jour du mois
• Monat
• Jour de la semaine
• Ordre

cPanel peut également proposer des programmes prédéfinis ou des paramètres généraux permettant de sélectionner plus facilement les intervalles fréquemment utilisés.

Comprendre les cinq champs temporels #

La syntaxe Cron classique se compose de cinq champs temporels :

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

Ensuite vient la commande à exécuter.

Le schéma se présente de manière simplifiée ainsi :

* * * * * Commande
│ │ │ │ │
│ │ │ │ └─ Jour de la semaine
│ │ │ └─── Mois
│ │ └───── Jour du mois
│ └─────── Heure
└───────── Minute

Que signifie l'étoile * ? #

Une étoile :

*

Dans un champ de temps Cron, le symbole * signifie fondamentalement que chaque valeur possible de ce champ est prise en compte.

Par exemple :

* * * * *

correspond à une exécution très fréquente, à savoir en principe chaque minute.

Attention : Utilise * * * * * pas sans réflexion. Un script lancé chaque minute peut consommer des ressources inutilement ou s'exécuter plusieurs fois en même temps si une exécution prend plus de temps.

4. Définir le calendrier #

Définissez maintenant la fréquence d'exécution de la tâche cron.

Si l'application utilisée impose un intervalle spécifique, tu dois en principe suivre cette recommandation.

Exemple : toutes les 5 minutes #

Un cron job toutes les cinq minutes utilise généralement :

*/5 * * * *

Cela signifie :

Minute :      */5
Heure :       *
Jour :        *
Mois :        *
Jour de la semaine : *

La commande sera ainsi exécutée en principe toutes les cinq minutes.

Exemple : toutes les 15 minutes #

*/15 * * * *

L'exécution a donc lieu en principe toutes les 15 minutes.

Exemple : toutes les heures #

Le cronjob doit-il être exécuté au début de chaque heure :

0 * * * *

Par exemple :

01:00
02:00
03:00
04:00
...

Exemple : tous les jours à 03h00 #

0 3 * * *

Cela signifie :

Minute:      0
Heure:       3
Jour:        *
Mois:        *
Jour de la semaine: *

Le travail cron s'exécute en principe une fois par jour à 03:00 selon l'heure du serveur déterminante pour l'exécution du cron.

Exemple : tous les jours à 03h30 #

30 3 * * *

Le cronjob sera ainsi exécuté fondamentalement tous les jours à 03h30.

Exemple : tous les lundis à 06h00 #

0 6 * * 1

Voici la 1 pour lundi.

Exemple : le premier jour de chaque mois #

Pour exécuter une tâche cron le premier jour de chaque mois à 02h00 :

0 2 1 * *

Exemple : toutes les six heures #

Une graphie possible est la suivante :

0 */6 * * *

Cela signifie que la commande est exécutée par principe selon un rythme de six heures.

Listes et plages dans les expressions Cron #

Cron prend en charge, outre les valeurs individuelles et les astérisques, d'autres notations.

Un trait d'union peut définir une plage :

1-5

Une liste séparée par des virgules peut spécifier plusieurs valeurs concrètes :

1,3,5

Une barre oblique peut être utilisée pour un intervalle :

*/10

La combinaison qui a du sens dépend du calendrier souhaité.

Utiliser des planifications cPanel prédéfinies #

Pour les intervalles fréquemment nécessaires, vous pouvez utiliser les paramètres généraux ou prédéfinis proposés par cPanel.

Cela réduit le risque de configurer accidentellement mal les cinq champs temporels.

Vérifie tout de même les valeurs générées à partir de cela, afin qu'elles correspondent bien au calendrier souhaité.

Faire la différence entre l'heure du serveur et l'heure locale #

Un point important concernant les tâches cron est le fuseau horaire sous-jacent.

L'heure du serveur déterminante pour l'exécution ne correspond pas nécessairement à votre heure locale.

Par conséquent, si un tâche cron doit s'exécuter à une heure locale spécifique, vous devez vérifier quelle zone horaire s'applique à l'exécution du cron.

Important : Si un cronjob semble s'exécuter une ou plusieurs heures „ trop tôt “ ou „ trop tard “, vérifiez d'abord le fuseau horaire avant de modifier le calendrier par simple présomption.

Prendre en compte l'heure d'été et l'heure d'hiver #

Les changements d'heure peuvent également jouer un rôle dans les tâches critiques en matière de temps.

Si et comment un changement d'heure affecte une tâche cron dépend de la configuration du fuseau horaire du système.

Si une tâche doit impérativement s'exécuter à une heure locale suisse spécifique, vous devez contrôler les temps d'exécution réels en conséquence.

5. Entrer la commande à exécuter #

Dans le champ Ordre vous entrez ce que le serveur doit exécuter à l'heure spécifiée.

La commande concrète dépend entièrement de l'application ou de la tâche concernée.

Dans le cas d'un script PHP, le principe de base peut par exemple ressembler à ceci :

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

Les chemins réels doivent correspondre à votre compte d'hébergement et à l'environnement PHP utilisé.

Attention : Ne copiez pas les chemins PHP de tutoriels d'hébergement tiers. Le chemin vers le binaire PHP peut différer selon le serveur, l'environnement PHP et la version de PHP.

Qu'est-ce qu'un binaire PHP ? #

Un binaire PHP est le programme PHP exécutable qui permet de lancer un script PHP via la ligne de commande.

Lors d'une requête Web, le serveur Web ou l'environnement PHP configuré traite le fichier PHP. En revanche, un travail cron nécessite une commande PHP exécutable adaptée lors d'un appel direct en CLI.

Simplifié :

Appel par navigateur :
Serveur web → PHP → Script

Tâche cron :
Binaire PHP → Script

Tenir compte de la version PHP du cronjob #

Si votre site Web utilise une version spécifique de PHP, vous devez vous assurer, lors de l'utilisation d'une tâche cron PHP, que la commande PHP exécutée correspond à l'application.

La version PHP du site web et la version PHP d'une commande en ligne ne sont pas automatiquement les mêmes.

Important : Un exécuté via SSH php -v ou un général PHPCette commande ne prouve pas automatiquement que exactement la même version de PHP est également utilisée pour votre site web ou votre tâche cron.

Vous gérez généralement la version PHP de votre domaine sur CURIAWEB via le MultiPHP-Manager.

Utiliser des chemins absolus #

Pour les tâches cron, vous devez utiliser des chemins absolus pour les scripts et les fichiers dans la mesure du possible.

Un chemin absolu commence au niveau du système de fichiers et désigne la destination de manière univoque.

Par exemple, de manière schématique :

/home/CPANELUSER/public_html/cron.php

Un chemin relatif tel que :

cron.php

dépend en revanche du répertoire de travail à partir duquel la commande est exécutée.

Cela peut entraîner des erreurs inattendues lors des exécutions automatiques de cron.

Ne pas confondre adresse web et chemin de système de fichiers #

Une URL telle que :

https://example.com/cron.php

n'est pas le même qu'un chemin de système de fichiers :

/home/CPANELUSER/public_html/cron.php

Une URL désigne une ressource via HTTP ou HTTPS. Un chemin de système de fichiers désigne un fichier directement sur le serveur.

La variante dont une application a besoin dépend de sa documentation.

Comment trouver le bon chemin d'accès au fichier ? #

Je suis Gestionnaire de fichiers cPanel pouvez-vous retracer la structure des répertoires de votre compte d'hébergement.

Par exemple, si votre domaine est associé à une racine de document spécifique, le script à exécuter se trouve dans cette structure de répertoires.

Ne pas utiliser automatiquement public_html, si le domaine concerné possède une autre racine de document.

Prendre en compte la racine du document d'un domaine supplémentaire #

Avec plusieurs domaines, chaque site web peut être associé à son propre répertoire.

Une tâche cron pour :

shop.example.com

ne doit donc pas nécessairement pointer vers un fichier situé sous :

/public_html/

montrer.

Vérifiez le chemin réel de l'application concernée.

6. Ajouter une tâche cron #

Si le calendrier et la commande sont saisis correctement, ajoutez le nouveau travail cron.

Le cronjob devrait ensuite apparaître dans la liste des cronjobs existants.

Vérifie encore une fois là-bas :

• Minute
• Heure
• Étiquette
• Monat
• Jour de la semaine
• Ordre

7. Tester d'abord le cronjob de manière contrôlée #

Pour une nouvelle tâche cron, vous ne devriez pas attendre plusieurs jours pour déterminer si la commande fonctionne.

Si l'application le permet, tu peux utiliser temporairement un intervalle plus court pour un test contrôlé.

Ensuite, tu remets le travail cron au calendrier réellement souhaité.

Attention : Utilisez un intervalle de test court uniquement si le processus exécuté peut être lancé plusieurs fois sans risque. Une importation, un processus d'expédition ou tout autre script modificateur ne doit pas être exécuté plusieurs fois de manière incontrôlée.

8. Vérifier le résultat de l'exécution #

La façon de savoir si le cronjob a réussi dépend de l'application exécutée.

Les options de contrôle possibles sont les suivantes :

• Sortie du travail cron
• Notification par e-mail
• Fichier journal de l'application
• Horodatage d'un fichier généré
• Statut au sein de l'application
• données traitées

Une entrée existante dans cPanel prouve seulement que la tâche cron a été configurée, et non que la commande exécutée fonctionne correctement.

Comprendre la sortie d'une tâche cron #

Une commande peut générer des sorties normales et des messages d'erreur.

Sous Linux, ils sont fondamentalement traités comme des canaux de sortie différents :

sortie standard

Cette distinction devient importante lorsque des sorties doivent être redirigées ou enregistrées.

Écrire la sortie dans un fichier journal #

Pour certains scripts personnels, il peut être utile de rediriger la sortie vers un fichier.

Un exemple schématique :

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

Cela signifie :

>>
→ Ajouter la sortie à un fichier

2>&1
→ Rediriger la sortie d'erreur vers la sortie standard

Utilisez uniquement des chemins qui existent dans votre compte d'hébergement et qui sont accessibles en écriture.

Les fichiers journaux peuvent devenir très volumineux #

Lorsqu'une tâche cron fréquemment exécutée enregistre plusieurs lignes à chaque exécution, un fichier journal peut considérablement grossir avec le temps.

Par conséquent, contrôlez régulièrement vos propres journaux cron ou utilisez une rotation des journaux appropriée si cela est prévu pour votre application.

Supprimer la sortie avec /dev/null #

Dans de nombreux tutoriels cron, tu trouveras des constructions telles que :

COMMANDE > /dev/null 2>&1

/dev/null rejette la sortie redirigée vers cet endroit.

Cela peut être judicieux dans le cas d'un cronjob fonctionnant de manière stable, si tu n'as sciemment pas besoin de la sortie.

Attention : Utilise /dev/null pas par réflexe pour un nouveau cronjob ou un cronjob défectueux. Tu pourrais rejeter exactement le message d'erreur dont tu as besoin pour le diagnostic.

Différence entre > et >> #

Lors de la redirection vers des fichiers, la différence est importante.

> écrit la sortie dans un fichier en remplaçant systématiquement le contenu précédent.

>> ajoute systématiquement la nouvelle édition au fichier existant.

Exemple :

COMMANDE > cron.log
→ Écrire dans le fichier (écraser)

COMMANDE >> cron.log
→ Ajouter la sortie à la fin du fichier

Que signifie 2>&1 ? #

L'orthographe :

2>&1

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

Cela permet aux messages normaux et aux messages d'erreur d'être consignés ensemble dans un fichier journal ou d'être ignorés ensemble.

Appel HTTP via une tâche cron #

Certaines applications ne fournissent pas de commande PHP-CLI directe, mais s'attendent à l'appel régulier d'une URL.

Selon l'environnement d'hébergement et les exigences de l'application, un outil de ligne de commande permettant de récupérer une adresse HTTP/HTTPS peut par exemple être utilisé à cet effet.

Dans ce cas, utilisez la commande recommandée par l'application.

Important : Ne remplacez pas un appel CLI prévu par l'application par un appel HTTP sans raison, ou inversement. Les deux variantes peuvent se comporter différemment sur le plan technique.

Distinguer l'appel CLI et l'appel HTTP #

Lors d'un appel direct en CLI PHP, le script PHP est exécuté via la ligne de commande.

En revanche, lors d'un appel HTTP, une adresse web est appelée, un peu comme par un navigateur ou un autre client HTTP.

Simplifié :

CLI :
Cron → PHP → Fichier

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

L'application détermine quelle variante est prévue.

Les variables d'environnement d'une tâche cron peuvent être différentes #

Un cron job ne s'exécute pas nécessairement avec exactement le même environnement qu'une session SSH interactive.

En particulier, les chemins de recherche et d'autres variables d'environnement peuvent différer.

C'est pourquoi une commande peut fonctionner dans un shell interactif alors que la même commande raccourcie échoue en tant que tâche cron.

Les chemins absolus vers les programmes et les fichiers réduisent de telles dépendances.

Le cronjob a besoin de droits d'écriture #

Si un script doit créer, modifier ou supprimer des fichiers, le processus exécuté a besoin des autorisations correspondantes.

Une erreur d'écriture ne signifie donc pas automatiquement que le planning Cron est erroné.

Vérifiez pour de tels problèmes :

• Chemin d'accès
• Répertoire
• Autorisations de fichiers
• Logique applicative

Vous trouverez les bases des autorisations de fichiers sur Définir correctement les autorisations de fichiers 644 et 755 dans cPanel.

Tâches cron et limites PHP #

Un script PHP exécuté via une tâche cron peut être soumis à des conditions différentes de celles d'un appel de page Web normal.

Si une tâche cron échoue en raison d'un besoin de mémoire ou d'un temps d'exécution trop long, il convient donc de vérifier en premier lieu quel environnement PHP exécute réellement la commande.

Nous traitons les limites PHP générales d'un site web sous Définir la limite de mémoire PHP, la taille de téléchargement et le temps d'exécution.

Important : Ne transférez pas automatiquement les valeurs de la configuration PHP Web vers PHP CLI. C'est l'environnement PHP qui exécute effectivement la commande cron qui est déterminant.

Tâches Cron et extensions PHP #

Les extensions PHP nécessaires peuvent également jouer un rôle dans un script PHP.

Si un script fonctionne via le site Web mais signale une fonction PHP manquante via une tâche Cron, il convient de vérifier si la tâche Cron utilise effectivement le même environnement PHP ou un environnement compatible.

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

Faire la distinction entre WP-Cron de WordPress et le cron du serveur #

WordPress possède WP-Cron un système personnalisé pour les tâches planifiées.

Cependant, WP-Cron n'est pas une tâche cron Linux classique.

Par défaut, WordPress vérifie les tâches planifiées lors des visites sur le site Web.

Simplifié :

Le visiteur accède à WordPress
→ WordPress vérifie les tâches planifiées
→ les événements WP-Cron dus peuvent être traités

Un véritable travail cron de serveur est en revanche lancé indépendamment d'une visite normale par le planificateur du serveur.

Pourquoi WP-Cron n'a pas besoin d'être précis à la minute près #

Lorsqu'un site web WordPress reçoit peu de visites ou des visites irrégulières, les tâches WP-Cron planifiées peuvent être déclenchées plus tard que prévu.

WP-Cron ne peut donc pas être assimilé à un cron système classique, qui s'exécute selon un calendrier fixe.

Remplacer WP-Cron par un véritable tâche Cron #

Sur certaines configurations WordPress, il peut être judicieux de déclencher régulièrement le traitement des tâches planifiées de WordPress via une véritable tâche Cron du serveur.

Cependant, cela devrait être configuré consciemment.

Si le mécanisme WP-Cron normal de WordPress est désactivé, il faut s'assurer que les tâches planifiées sont ensuite déclenchées de manière fiable via le mécanisme alternatif.

Attention : Ne désactive pas simplement WP-Cron dans wp-config.php, sans avoir préalablement configuré et testé un remplacement fonctionnel. Sinon, les tâches WordPress planifiées risquent de ne pas s'exécuter.

Comprendre DISABLE_WP_CRON #

Dans WordPress, le mécanisme d'appel normal de WP-Cron peut être défini via une constante dans le fichier wp-config.php être influencé.

Une configuration correspondante peut par exemple contenir :

define( 'DISABLE_WP_CRON', true );

Cela ne devrait être utilisé que si un autre mécanisme fonctionnel pour le traitement des tâches cron de WordPress est consciemment mis en place.

La modification du fichier wp-config.php doit être sauvegardé au préalable et exécuté avec soin.

WooCommerce et les tâches cron #

WooCommerce et les extensions WooCommerce utilisent des tâches planifiées ou d'arrière-plan pour divers processus.

Selon la configuration, cela peut par exemple inclure des actions planifiées, des notifications, des synchronisations ou d'autres processus d'arrière-plan.

Ne modifiez donc pas la configuration Cron d'une boutique WooCommerce de production à la légère.

Choisir la fréquence en fonction de la tâche #

Une tâche cron ne doit pas être exécutée plus souvent que techniquement nécessaire.

Si une tâche n'est nécessaire qu'une seule fois par jour, il n'y a généralement aucune raison de la lancer chaque minute.

Une fréquence inutilement élevée peut :

• nécessiter un temps de processeur supplémentaire
• Créer des processus PHP
• déclencher des requêtes de base de données
• surcharger les API externes
• entraîner des versions qui se chevauchent

Éviter les tâches cron qui se chevauchent #

Un cas particulièrement important se présente lorsqu'un cronjob est lancé plus souvent que son exécution ne dure.

Exemple :

Le travail cron démarre toutes les 5 minutes
L'exécution prend 8 minutes

Ainsi, la prochaine exécution peut commencer alors que la précédente n'est pas encore terminée.

Selon l'application, cela peut entraîner l'exécution simultanée de plusieurs processus identiques.

Attention : Pour les longs imports, les synchronisations ou les tâches gourmandes en calcul, vous devez vous assurer que l'intervalle choisi correspond à la durée d'exécution réelle ou que l'application empêche les exécutions parallèles.

Tâches cron et ressources CloudLinux #

Un cronjob consomme également des ressources d'hébergement.

Un script fréquemment exécuté ou gourmand en ressources de calcul peut, par exemple, solliciter le processeur, la mémoire vive, les processus ou les ressources de la base de données.

Si une tâche cron coïncide régulièrement avec une charge élevée, sa durée d'exécution et sa fréquence doivent être vérifiées.

Nous traitons l'évaluation des ressources sous Comprendre l'utilisation des ressources CloudLinux dans cPanel.

Éviter de lancer plusieurs tâches cron lourdes à la même minute #

Si vous exécutez plusieurs tâches gourmandes en ressources, il peut être judésiable d'en échelonner les heures de démarrage.

Au lieu de, par exemple, trois processus complexes tout autour :

03:00

pour commencer, des heures de démarrage différentes peuvent être utilisées, pour autant que les applications le permettent.

Cela évite de créer inutilement plusieurs pics de charge en même temps.

Tester une tâche cron manuellement #

Si vous disposez d'un accès SSH et que vous connaissez précisément la commande utilisée, un test manuel peut s'avérer utile.

Cela permet de faire la distinction entre :

• la commande elle-même est erronée
• ou si seule l'exécution automatique du cron pose des problèmes

Cependant, un test manuel ne devrait être effectué que si la tâche concernée peut être réexécutée sans danger.

Le test manuel fonctionne, la tâche cron non #

Si une commande fonctionne manuellement mais pas en tant que tâche cron, vous devez particulièrement vérifier :

• chemins absolus
• PHP-Binary
• Variables d'environnement
• Autorisations
• Planification Cron
• Sorties et messages d'erreur

Nous traitons le dépannage systématique dans l'article La tâche cron ne fonctionne pas : causes et solutions.

Le cronjob ne semble pas s'exécuter #

Si une tâche n'est pas exécutée à l'heure prévue, vérifiez d'abord le planning.

Une erreur fréquente est la confusion entre :

• Minute et heure
• Jour du mois et jour de la semaine
• heure locale et heure du serveur
• intervalle et moment précis

Vérifiez ensuite la commande elle-même.

Le cronjob tourne, mais le script génère des erreurs #

Dans ce cas, l'exécution programmée peut fonctionner, tandis que le script proprement dit échoue.

Ce sont deux niveaux différents :

Cron lance la commande
→ fonctionne

Le script s'exécute
→ génère une erreur

Examinez ensuite le message d'erreur du script ou ses propres fichiers journaux.

Enregistrer les erreurs PHP #

Lorsqu'un script PHP génère une erreur, une journalisation appropriée peut s'avérer utile selon la configuration.

En cas d'erreurs de site Web, nous expliquons les journaux cPanel sur Lire le journal des erreurs cPanel et trouver les erreurs du site Web.

Notez toutefois qu'une tâche cron en CLI n'utilise pas nécessairement les mêmes journaux ni la même configuration PHP qu'un appel web normal.

Modifier le cronjob #

Les tâches cron existantes sont répertoriées dans la section des tâches cron de cPanel.

Si vous souhaitez modifier un horaire ou une commande, vérifiez l'entrée précédente avant d'effectuer la modification.

Pour les commandes plus complexes, il peut être judicieux de copier ou de documenter l'ancienne valeur au préalable.

Supprimer le cronjob #

Lorsqu'un cronjob n'est plus nécessaire, vous pouvez le supprimer via la fonction correspondante.

Vérifiez avant la suppression si l'application associée a toujours besoin de la tâche cron.

Attention : La suppression d'une tâche cron ne supprime pas automatiquement l'application associée. Cependant, cela peut entraîner l'arrêt de l'exécution de ses tâches de fond planifiées.

Vérifier les anciens cronjobs après le déplacement du site Web #

Après une migration ou une modification du compte d'hébergement, vous devez vérifier les tâches cron existantes.

Les chemins absolus peuvent changer en cas de déplacement.

Par exemple, une ancienne commande peut encore pointer vers un répertoire qui n'existe pas sur le nouvel hébergement.

Vérifier les tâches cron après le changement de version de PHP #

Lorsqu'une application est mise à niveau vers une autre version de PHP, vous devez également tenir compte des tâches cron basées sur PHP.

Une tâche cron avec un chemin d'accès au binaire PHP codé en dur peut continuer à appeler une version de PHP différente de celle du site web.

Vérifiez par conséquent, après des modifications PHP pertinentes, si les scripts PHP programmés continuent de fonctionner avec l'environnement prévu.

Ne pas écrire de données sensibles directement dans les commandes cron #

Évitez dans la mesure du possible d'inscrire des mots de passe, des clés API ou d'autres identifiants confidentiels directement dans une commande cron.

De telles informations doivent être configurées en toute sécurité en fonction de l'application respective.

Sécuriser les scripts cron accessibles au public #

Si une tâche cron appelle une URL accessible via le web, vous devez vérifier si cette URL peut également être déclenchée par n'importe quel visiteur.

Pour les tâches sensibles ou gourmandes en ressources, une application peut prévoir ses propres mécanismes de protection.

Utilisez la protection recommandée par le fabricant respectif.

Exemples de calendriers courants #

Exécution souhaitée	Planification Cron
Chaque minute	* * * * *
Toutes les 5 minutes	*/5 * * * *
Toutes les 15 minutes	*/15 * * * *
Au début de chaque heure	0 * * * *
Tous les jours à 03h00	0 3 * * *
Tous les jours à 03h30	30 3 * * *
Tous les lundis à 06h00	0 6 * * 1
Le 1er de chaque mois à 02:00	0 2 1 * *
Toutes les 6 heures à l'heure pile	0 */6 * * *

Liste de contrôle avant d'enregistrer une tâche cron #

Vérifiez avant d'ajouter :

• Le bon script ou la bonne commande est-il ou elle renseigné(e) ?
• Utilises-tu des chemins absolus ?
• L'environnement PHP approprié est-il pris en compte pour les scripts PHP ?
• Est-ce que l'intervalle est vraiment nécessaire ?
• La tâche peut-elle prendre plus de temps que l'intervalle ?
• La zone horaire pertinente est-elle prise en compte ?
• As-tu besoin de la sortie pour les premiers tests ?
• La tâche peut-elle être exécutée plusieurs fois sans risque ?

Procédure recommandée pour une nouvelle tâche cron #

1. Consultez la documentation de l'application utilisée.
2. Notez la commande requise et l'intervalle recommandé.
3. Connectez-vous à cPanel.
4. Ouvrir Options avancées → Tâches Cron.
5. Vérifiez le paramètre pour les sorties d'e-mails cron.
6. Définissez le calendrier souhaité.
7. Vérifiez la minute, l'heure, le jour, le mois et le jour de la semaine.
8. Prenez en compte le fuseau horaire applicable pour la tâche cron.
9. Entrez la commande complète.
10. Utilisez des chemins absoluts pour les fichiers dans la mesure du possible.
11. Vérifiez le binaire PHP utilisé dans les scripts PHP.
12. N'supprimez pas inutilement les messages d'erreur lors du premier test.
13. Ajoute la tâche cron.
14. Vérifiez l'entrée enregistrée.
15. Vérifiez après la première exécution si la tâche a été accomplie avec succès.
16. Rétablissez ensuite un calendrier de test temporairement raccourci à l'intervalle souhaité.

Quand devez-vous contacter le support CURIAWEB ? #

Si une tâche cron ne fonctionne pas malgré un calendrier correct et que vous ne parvenez pas à en identifier la cause, documentez l'entrée existante aussi précisément que possible.

Pour une analyse, les informations suivantes sont notamment utiles :

• domaine ou application concerné
• commande cron complète sans informations d'identification confidentielles
• programme défini
• date d'exécution prévue
• comportement effectivement observé
• version de PHP utilisée ou binaire PHP, le cas échéant
• message d'erreur complet
• si la commande fonctionne manuellement
• si le travail cron fonctionnait déjà auparavant

Ne transmettez pas de mots de passe, de clés API ou d'autres identifiants de connexion confidentiels.

Résumé #

Les tâches cron vous permettent d'exécuter automatiquement des commandes et des scripts sur votre hébergement web CURIAWEB selon un calendrier défini. Vous trouverez la gestion sous Options avancées → Tâches Cron.

Une tâche cron se compose de cinq champs de temps pour la minute, l'heure, le jour, le mois et le jour de la semaine, ainsi que de la commande à exécuter. Les planifications couramment utilisées sont, par exemple, */5 * * * * toutes les cinq minutes ou 0 3 * * * pour une exécution quotidienne à 03h00.

Utilisez autant que possible des chemins de fichiers absolus pour les scripts et tenez compte du fait que, pour les tâches cron PHP, la version de PHP d'une commande en ligne n'est pas nécessairement identique à celle du site Web.

N'supprimez pas trop rapidement les sorties et les messages d'erreur d'une nouvelle tâche cron avec /dev/null. Vous êtes souvent la source d'information la plus importante lors de l'installation et du dépannage.

Veillez également à ne pas exécuter une tâche cron plus souvent que nécessaire. Si une tâche prend plus de temps que son intervalle d'exécution, plusieurs processus risquent de se lancer simultanément et de consommer inutilement des ressources d'hébergement.

Sous WordPress, vous devez également faire la distinction entre le WP-Cron natif de WordPress et un véritable travail cron (cronjob) du serveur. Si WP-Cron est désactivé, un mécanisme d'exécution alternatif fonctionnel doit être présent.

La règle la plus importante est : Vérifier séparément le calendrier, la commande, le chemin du fichier et l'environnement d'exécution. Une tâche cron correctement enregistrée ne garantit pas automatiquement que le script appelé s'exécutera avec succès.