Aide-mémoire Linux Cron

Vous avez déployé votre application Node sur un serveur Linux et vous avez besoin d’exécuter un script chaque nuit à 3 heures du matin. Vous avez entendu parler de cron, mais la syntaxe semble cryptique et les tutoriels que vous avez trouvés sont soit obsolètes, soit remplis d’inexactitudes. Cet aide-mémoire Linux cron vous fournit la référence correcte et adaptée aux distributions dont vous avez besoin pour une planification fiable des tâches cron.

Syntaxe Crontab : Le format à cinq champs

Chaque tâche cron suit cette structure :

┌───────────── minute (0-59)
│ ┌─────────── hour (0-23)
│ │ ┌───────── day of month (1-31)
│ │ │ ┌─────── month (1-12)
│ │ │ │ ┌───── day of week (0-6, Sunday=0)
│ │ │ │ │
* * * * * command

Caractères spéciaux :

• * — n’importe quelle valeur
• , — séparateur de liste (1,3,5)
• - — plage (1-5)
• / — valeurs de pas (*/15 signifie toutes les 15)

Important : Les caractères comme L, W, # et ? appartiennent à la syntaxe du planificateur Quartz, pas au cron standard. Ne les utilisez pas dans les crontabs Linux. En cas de doute, consultez la documentation de votre système via man 5 crontab.

Modèles de planification courants

*/5 * * * *     # Toutes les 5 minutes
0 * * * *       # Au début de chaque heure
0 3 * * *       # Quotidiennement à 3 heures du matin
0 0 * * 0       # Hebdomadaire le dimanche à minuit
0 0 1 * *       # Premier jour de chaque mois

Chaînes spéciales

La plupart des implémentations de cron prennent en charge ces raccourcis (la prise en charge peut varier sur les systèmes minimaux comme BusyBox) :

Notez que @reboot ne garantit pas que le réseau ou d’autres services soient disponibles ; pour les tâches de démarrage nécessitant des dépendances, les timers systemd sont généralement plus adaptés.

Le piège Jour du mois vs Jour de la semaine

Lorsque vous spécifiez à la fois le jour du mois ET le jour de la semaine, cron les traite comme un OU, et non un ET :

0 0 15 * 1    # S'exécute le 15 OU n'importe quel lundi

Cela prend beaucoup de gens au dépourvu. Si vous avez besoin « du 15, mais seulement si c’est un lundi », gérez cette logique dans votre script.

Gestion de l’environnement

Cron s’exécute avec un environnement limité et non interactif. C’est là que la plupart des tâches échouent silencieusement.

Le comportement de PATH varie selon la distribution et la version :

• Certains systèmes définissent un PATH par défaut minimal
• D’autres (notamment les versions récentes d’Ubuntu) peuvent hériter PATH de l’environnement du service

Ne comptez pas sur les valeurs par défaut. Pour un comportement portable et prévisible, définissez explicitement ce dont vous avez besoin.

Bonnes pratiques :

# Définir les variables en haut de votre crontab
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=""

# Toujours utiliser des chemins absolus
0 3 * * * /usr/bin/node /home/deploy/app/cleanup.js

Remarque : MAILTO ne fonctionne que si un MTA local est installé et configuré. De nombreux serveurs modernes n’en ont pas. Redirigez plutôt la sortie explicitement au lieu de vous fier aux e-mails.

Sortie et journalisation

# Tout journaliser
0 3 * * * /path/to/script.sh >> /var/log/myjob.log 2>&1

# Ignorer toute sortie
0 3 * * * /path/to/script.sh >/dev/null 2>&1

# Journaliser uniquement les erreurs
0 3 * * * /path/to/script.sh >/dev/null 2>> /var/log/myjob-errors.log

Commandes crontab essentielles

crontab -e    # Éditer votre crontab
crontab -l    # Lister les tâches actuelles
crontab -r    # Supprimer toutes les tâches (attention !)

Pour les tâches à l’échelle du système, utilisez les fichiers /etc/cron.d/. Notez que /etc/cron.daily/, /etc/cron.hourly/, etc. sont exécutés via run-parts, et non analysés automatiquement par cron. Consultez man 8 run-parts pour les règles de nommage et d’exécution.

Les implémentations de cron varient

Différents systèmes exécutent différents démons cron :

• Debian/Ubuntu : cron (lignée Vixie, patché par la distribution)
• RHEL/Fedora : Cronie
• Alpine/conteneurs : BusyBox crond

La prise en charge des fonctionnalités (chaînes spéciales, comportement des e-mails, journalisation) peut différer. Vérifiez toujours par rapport à la page de manuel locale crontab(5).

Cron vs Timers Systemd

Utilisez cron quand : Vous avez besoin d’une planification simple et portable qui fonctionne partout.

Utilisez les timers systemd quand : Vous avez besoin de gestion des dépendances, de planification persistante entre les redémarrages, ou d’une meilleure intégration avec les systèmes Linux modernes. La documentation du projet systemd sur les unités timer est la référence canonique.

Liste de vérification rapide pour le débogage

1. Cron est-il en cours d’exécution ? systemctl status cron ou systemctl status crond (le nom du service varie selon la distribution)
2. Vérifiez les journaux : grep CRON /var/log/syslog (Debian/Ubuntu) ou /var/log/cron (RHEL/Fedora)
3. Testez votre commande manuellement avec un environnement restreint
4. Vérifiez les chemins absolus pour toutes les commandes et fichiers
5. Vérifiez les permissions de fichier sur votre script

Conclusion

Cron reste le moyen le plus simple de planifier des tâches sur Linux. Maîtrisez la syntaxe à cinq champs, comprenez le comportement OU lors de la combinaison des champs de jour, et tenez compte du comportement d’environnement spécifique à la distribution. Avec ces fondamentaux en place, vos tâches planifiées s’exécuteront de manière fiable pendant des années.

FAQ

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.