← Blog

Blog · Dépannage

Mon script fonctionne à la main mais pas en cron

Le script tourne parfaitement dans votre shell et ne fait rien à l'heure prévue. Neuf fois sur dix, c'est l'environnement, pas le script. Voici les coupables habituels.

D'abord, voyez ce que cron voit vraiment

Cron exécute votre job avec un environnement minimal et sans terminal, donc la moindre erreur disparaît. Avant de deviner, capturez la sortie dans un fichier de log :

 crontab
0 3 * * * /usr/local/bin/job.sh >> /var/log/job.log 2>&1

La prochaine exécution laisse un vrai message d'erreur au lieu du silence, et c'est en général l'une de ces causes :

1. Le PATH est presque vide

Le PATH de cron est minimal : python, node ou pg_dump sont souvent introuvables. Utilisez des chemins absolus (/usr/bin/python3), ou définissez PATH en haut de la crontab :

 haut de la crontab
PATH=/usr/local/bin:/usr/bin:/bin

2. Mauvais répertoire de travail

Cron démarre dans le répertoire personnel de l'utilisateur, pas dans votre projet : les chemins relatifs cassent. Faites d'abord un cd au bon endroit, ou passez tous les chemins en absolu :

 crontab
0 3 * * * cd /srv/app && ./run.sh

3. Variables d'environnement manquantes

Cron ne lit ni ~/.bashrc ni ~/.profile : des variables comme DATABASE_URL ne sont tout simplement pas définies. Chargez-les explicitement dans le script, par ex. set -a; . /srv/app/.env; set +a, ou définissez-les dans la crontab.

4. Un % non échappé dans la commande

Dans une ligne de crontab, % signifie un retour à la ligne. Une commande comme date +%Y-%m-%d est silencieusement coupée au premier %. Échappez chacun avec un antislash :

 crontab
0 3 * * * /usr/local/bin/backup.sh db-$(date +\%Y-\%m-\%d).sql

5. Mauvais utilisateur ou permissions

crontab -e édite la crontab de l'utilisateur courant : un job qui a besoin de root, ou un fichier que vous seul pouvez lire, échoue quand il s'exécute sous l'utilisateur cron. Vérifiez dans quelle crontab il se trouve, et que le script est exécutable (chmod +x).

Corrigé ? Vous avez réglé le problème du jour. Cron ne vous dira toujours pas si le même job s'arrête en silence le mois prochain, après un redémarrage, un mauvais déploiement, ou une ligne de crontab supprimée.

Le savoir la prochaine fois, automatiquement

Cette seconde moitié, c'est exactement ce qu'est Mortemain : un interrupteur homme mort pour vos jobs planifiés. Votre job fait son check-in à chaque exécution avec une requête HTTP, et si un check-in manque, Mortemain vous alerte. Aucun agent, aucun SDK, hébergé dans l'UE.

Essayez Mortemain gratuitement (20 checks, sans carte bancaire).