AI-TOL
🔧 Troubleshooting 🕐 10 min read 10 Common Mistakes

Erreurs Courantes des Expressions Cron à Éviter

Découvrez les erreurs les plus courantes des expressions cron et comment les corriger. Évitez ces pièges lors de la planification des tâches avec cron.

Having trouble? Try the tool

Test your with our interactive tool

Open →

Top 10 Common Mistakes

🚨
Mistake #1 CRITICAL

Utiliser des Chemins Relatifs au Lieu de Chemins Absolus

Symptoms

  • • Les commandes échouent avec des erreurs "command not found"
  • • Les scripts s'exécutent manuellement mais échouent dans cron
  • • Échecs intermittents selon le répertoire actuel

Root Cause

Les tâches cron s'exécutent dans un environnement minimal avec un répertoire de travail imprévisible (souvent le répertoire personnel de l'utilisateur ou /root). Les chemins relatifs dépendent du répertoire actuel, ce qui n'est pas garanti dans le contexte cron.

Solution

Utilisez toujours des chemins absolus pour toutes les commandes, scripts et références de fichiers. Définissez explicitement le répertoire de travail avec `cd` si nécessaire.

❌ Wrong


                      # Faux - utilise des chemins relatifs
*/5 * * * * python script.py
*/5 * * * * ./scripts/backup.sh

✅ Correct

                      # Correct - utilise des chemins absolus
*/5 * * * * /usr/bin/python3 /opt/scripts/script.py
*/5 * * * * cd /opt/scripts && ./backup.sh
*/5 * * * * /opt/scripts/backup.sh
🚨
Mistake #2 CRITICAL

Ignorer les Variables d'Environnement

Symptoms

  • • Les scripts fonctionnent dans le shell mais échouent dans cron
  • • Commandes non trouvées alors qu'elles sont dans PATH lors de l'exécution manuelle
  • • Les applications échouent en raison d'une configuration d'environnement manquante

Root Cause

Cron s'exécute avec un environnement sévèrement limité - généralement seulement HOME, LOGNAME, SHELL et un PATH minimal (/usr/bin:/bin). Les variables d'environnement de votre profil shell (.bashrc, .zshrc) ne sont pas chargées.

Solution

Définissez explicitement les variables d'environnement requises dans la crontab ou le script. Définissez PATH et toutes les variables spécifiques à l'application.

❌ Wrong


                      # Faux - suppose l'environnement shell
*/5 * * * * python script.py
*/5 * * * * ./data_process.sh

✅ Correct

                      # Correct - environnement explicite
PATH=/usr/local/bin:/usr/bin:/bin
NODE_ENV=production
DB_HOST=localhost

*/5 * * * * /usr/bin/python3 /opt/scripts/script.py
*/5 * * * * /opt/scripts/data_process.sh
⚠️
Mistake #3 HIGH

Oublier de Rediriger la Sortie et les Erreurs

Symptoms

  • • Aucun moyen de déboguer les tâches cron échouées
  • • La sortie est envoyée par e-mail système (souvent jamais lue)
  • • L'espace disque se remplit de sortie non journalisée

Root Cause

Par défaut, cron envoie toute sortie au propriétaire de la tâche par e-mail. Sans redirection explicite, les erreurs et les logs sont perdus dans les e-mails ou le vide.

Solution

Redirigez toujours stdout et stderr vers des fichiers日志. Utilisez `>>` pour ajouter et `2>&1` pour rediriger les deux flux.

❌ Wrong


                      # Faux - la sortie va aux e-mails ou est perdue
*/5 * * * * /opt/scripts/check.sh

✅ Correct

                      # Correct - la sortie est journalisée dans un fichier
*/5 * * * * /opt/scripts/check.sh >> /var/log/check.log 2>&1
*/5 * * * * /opt/scripts/check.sh 1>> /var/log/check.out.log 2>> /var/log/check.err.log
⚠️
Mistake #4 HIGH

Utiliser à la Fois le Jour du Mois et le Jour de la Semaine

Symptoms

  • • Les tâches s'exécutent plus fréquemment que prévu
  • • Les tâches s'exécutent à des jours inattendus
  • • Confusion sur le moment d'exécution des tâches

Root Cause

Dans cron standard, si le jour du mois (1-31) ET le jour de la semaine (0-6) sont tous deux restreints (non *), la tâche s'exécute lorsque l'un ou l'autre des champs correspond. C'est une source courante de confusion.

Solution

Utilisez `?` ou `*` pour l'un des champs lorsque vous voulez restreindre l'autre. Si vous avez besoin du "15 et seulement si c'est un lundi", implémentez la logique dans le script lui-même.

❌ Wrong


                      # Faux - s'exécute le 15 de chaque mois OU chaque vendredi
0 0 15 * 5 /script.sh  # S'exécute le 15 de chaque mois ET chaque vendredi

✅ Correct

                      # Correct - ne s'exécute que le vendredi 15 (logique dans le script)
0 0 * * 5 /scripts/check_friday_15th.sh  # Le script vérifie si c'est le 15

# OU utilisez cron moderne avec ? pour le champ non restrictif
0 0 15 * ? /scripts/monthly.sh  # S'exécute le 15, jour de la semaine ignoré
0 0 ? * 5 /scripts/weekly.sh    # S'exécute chaque vendredi, jour ignoré
🚨
Mistake #5 CRITICAL

Absence de Permissions d'Exécution sur les Scripts

Symptoms

  • • La tâche cron échoue avec "Permission denied"
  • • La tâche est planifiée mais ne s'exécute jamais
  • • Pas de message d'erreur ou erreur cryptique dans les日志

Root Cause

Les scripts doivent avoir des permissions d'exécution (+x) pour être exécutés directement. Sans permissions d'exécution, le script ne peut pas être invoqué par cron.

Solution

Définissez toujours les permissions d'exécution sur les scripts avec `chmod +x`. Alternativement, appelez le script explicitement avec l'interpréteur (ex: `bash script.sh`).

❌ Wrong


                      # Faux - le script n'est peut-être pas exécutable
*/5 * * * * /opt/scripts/myscript.sh

✅ Correct

                      # Options correctes :
# 1. Rendre le script exécutable
$ chmod +x /opt/scripts/myscript.sh
*/5 * * * * /opt/scripts/myscript.sh

# 2. Appeler avec l'interpréteur
*/5 * * * * /bin/bash /opt/scripts/myscript.sh

# 3. Ajouter shebang et rendre exécutable
#!/bin/bash
# contenu du script
⚠️
Mistake #6 HIGH

Gestion Incorrecte du Fuseau Horaire

Symptoms

  • • Les tâches s'exécutent au mauvais moment
  • • Les tâches s'exécutent une heure trop tôt ou trop tard
  • • Comportement incohérent entre les systèmes

Root Cause

Cron utilise le fuseau horaire configuré du système. Dans les environnements cloud ou conteneurs, il peut s'agir d'UTC plutôt que de votre fuseau horaire local. Les changements d'heure (heure d'été) peuvent également affecter la planification.

Solution

Définissez explicitement le fuseau horaire dans la crontab avec CRON_TZ, ou utilisez UTC universellement. Documentez le fuseau horaire que votre cron suppose.

❌ Wrong


                      # Faux - suppose le fuseau horaire système (peut varier)
0 9 * * * /scripts/morning_report.sh  # S'exécute à 9h, mais quel fuseau?

✅ Correct

                      # Correct - fuseau horaire explicite
CRON_TZ=Europe/Paris
0 9 * * * /scripts/morning_report.sh  # 9h heure de Paris

# OU utilisez UTC et documentez
# Toutes les heures cron en UTC
0 8 * * * /scripts/morning_report.sh  # 9h Paris = 8h UTC
⚡
Mistake #7 MEDIUM

Ne Pas Gérer les Tâches Superposées

Symptoms

  • • Plusieurs instances de la même tâche s'exécutent
  • • Épuisement des ressources dû aux processus en double
  • • Corruption des données due aux écritures simultanées
  • • Conditions de course dans les fichiers de sortie

Root Cause

Si une tâche prend plus de temps que son intervalle planifié, cron lancera une autre instance pendant que la première est encore en cours d'exécution. Cela conduit à des exécutions superposées.

Solution

Utilisez des verrous de fichiers (flock) ou des vérifications de processus (pgrep) pour assurer qu'une seule instance s'exécute. Pour les tâches critiques, utilisez systemd ou supervisord avec une gestion appropriée des mutex.

❌ Wrong


                      # Faux - peut démarrer des superpositions si le script dure >5 min
*/5 * * * * /scripts/data_sync.sh

✅ Correct

                      # Correct - empêche les superpositions
# Méthode 1: flock
*/5 * * * * /usr/bin/flock -w 0 /tmp/data_sync.lock -c /scripts/data_sync.sh

# Méthode 2: vérification pid dans le script
if [ -f /tmp/myscript.pid ]; then
  pid=$(cat /tmp/myscript.pid)
  if ps -p $pid > /dev/null; then
    echo "Already running"
    exit 1
  fi
fi
echo $$ > /tmp/myscript.pid
trap "rm -f /tmp/myscript.pid" EXIT
⚡
Mistake #8 MEDIUM

Planifier des Tâches Gourmandes en Ressources Pendant les Heures de Pointe

Symptoms

  • • Dégradation des performances du système pendant les heures de travail
  • • Plaintes concernant la lenteur des systèmes
  • • Les tâches cron concurrencent l'activité des utilisateurs
  • • Pic de charge à des moments prévisibles

Root Cause

Les tâches gourmandes en ressources (sauvegardes, traitement par lots, rapports) planifiées pendant les heures d'utilisation maximale concurrencent le CPU, la mémoire et les E/S avec les utilisateurs actifs.

Solution

Planifiez les tâches gourmandes en ressources pendant les heures creuses (tard la nuit, tôt le matin). Surveillez la charge du système et ajustez les planifications en conséquence.

❌ Wrong


                      # Faux - sauvegarde lourde pendant la journée de travail
0 10 * * * /scripts/heavy_backup.sh  # 10h - heures de pointe
0 14 * * * /scripts/data_processing.sh  # 14h - aussi très chargé

✅ Correct

                      # Correct - planification hors pointe
0 2 * * * /scripts/heavy_backup.sh   # 2h du matin - activité minimale
0 3 * * 0 /scripts/weekly_report.sh  # Dimanche 3h - week-end
0 6 * * 1 /scripts/monthly_cleanup.sh  # Lundi 6h - avant le travail

# Vérifier la charge système avant d'exécuter
*/30 * * * * /usr/bin/bash -c '[[ $(cat /proc/loadavg | awk '{print $1}'`) < 2.0 ]] && /scripts/light_task.sh'
⚡
Mistake #9 MEDIUM

Oublier de Tester les Nouvelles Tâches Cron

Symptoms

  • • Les tâches échouent silencieusement en production
  • • Erreurs de syntaxe découvertes après le déploiement
  • • Comportement inattendu dans l'environnement cron
  • • Correctifs d'urgence requis à des moments inopportuns

Root Cause

Les expressions cron et les scripts qui fonctionnent dans un environnement de test peuvent échouer en production en raison de différents chemins, variables d'environnement, permissions ou configurations système.

Solution

Testez toujours les tâches cron avant le déploiement en production. Testez le script manuellement, validez la syntaxe de l'expression cron et surveillez les premières exécutions.

❌ Wrong


                      # Faux - non testé en production
0 0 * * * /scripts/new_feature.sh  # Ajouté directement en prod

✅ Correct

                      # Correct - workflow de test
# 1. Tester le script manuellement
$ /scripts/new_feature.sh

# 2. Valider la syntaxe cron
$ crontab -l | grep new_feature
# ou utiliser un validateur en ligne

# 3. Tester d'abord avec une planification fréquente
*/5 * * * * /scripts/new_feature.sh  # Exécuter toutes les 5 min pour tester
# Vérifier: tail -f /var/log/new_feature.log

# 4. Une fois validé, mettre à jour vers la planification cible
0 0 * * * /scripts/new_feature.sh
🚨
Mistake #10 CRITICAL

Ignorer l'État du Service Cron

Symptoms

  • • Les tâches cron arrêtent mystérieusement de s'exécuter
  • • Pas de日志 ou messages d'erreur
  • • Les tâches fonctionnent après redémarrage mais échouent plus tard
  • • Planification peu fiable

Root Cause

Le service cron ou crond peut être arrêté, désactivé ou défaillant. Les mises à jour système ou les changements de configuration peuvent arrêter le service sans notification.

Solution

Surveillez l'état du service cron et configurez des alertes. Assurez-vous que le service est activé pour démarrer au démarrage.

❌ Wrong


                      # Faux - suppose que cron est toujours en cours d'exécution
# Pas de surveillance ou vérification

✅ Correct

                      # Correct - surveiller le service cron
# Vérifier l'état du service
$ systemctl status cron
$ systemctl status crond

# Activer au démarrage
$ sudo systemctl enable cron
$ sudo systemctl start cron

# Surveiller avec un contrôle de santé
*/15 * * * * /usr/bin/systemctl is-active cron || /usr/bin/systemctl restart cron

# Alerte si cron échoue
*/15 * * * * /usr/bin/systemctl is-active --quiet cron || echo "Cron arrêté!" | mail -s "Alerte" [email protected]

Still Having Trouble?

Try the interactive tool to test and debug

Open →