Cron et crontab sous Linux, automatiser sans créer de panne silencieuse

Planifier une commande avec cron paraît simple jusqu’au jour où la tâche ne se lance pas, se lance deux fois, tourne avec le mauvais utilisateur ou écrit dans un chemin introuvable. Sous Linux, cron reste pourtant l’outil le plus direct pour exécuter des sauvegardes, nettoyages, exports, contrôles de service ou scripts de maintenance à heure fixe.

La bonne approche consiste à traiter une ligne crontab comme un petit contrat d’exploitation : un horaire clair, un utilisateur identifié, un chemin absolu, une sortie suivie et une méthode de test. C’est ce qui transforme une automatisation fragile en tâche planifiée fiable.

Comprendre ce que cron exécute vraiment

Cron est un service qui vérifie les planifications et lance les commandes au moment prévu. Il ne “devine” pas votre environnement interactif. Une tâche lancée par cron ne bénéficie pas forcément de votre terminal, de vos alias, de votre répertoire courant, ni de toutes les variables chargées dans votre session. Cette différence explique une grande partie des pannes, notamment sur les serveurs où plusieurs versions d’un même outil coexistent.

Une crontab n’est donc pas seulement une liste d’horaires. Elle indique qui exécute, quand exécuter et quelle commande lancer. Dans une crontab utilisateur, la commande tourne avec les droits de cet utilisateur. Dans les fichiers système comme /etc/crontab ou certains fichiers sous /etc/cron.d/, un champ utilisateur peut s’ajouter avant la commande. Confondre ces deux formats produit des lignes invalides ou des jobs lancés avec le mauvais contexte.

Le premier réflexe professionnel consiste à écrire chaque job comme s’il devait être relu dans six mois par une autre personne. Ajoutez un commentaire utile, utilisez des chemins absolus et redirigez la sortie vers un fichier ou un journal. Une crontab compacte, sans trace et sans contexte, est facile à créer mais difficile à maintenir quand une alerte arrive un dimanche matin.

Lire la syntaxe crontab sans se tromper

Retenez d’abord l’ordre. Vérifiez ensuite les valeurs, puis seulement la commande appelée et son contexte réel d’exécution.

Une ligne crontab utilisateur suit généralement cinq champs temporels, puis la commande. L’ordre ne change pas : minute, heure, jour du mois, mois, jour de semaine. Un astérisque signifie “toutes les valeurs possibles” pour le champ concerné.

Ce premier exemple exécute un script chaque jour à 2 h 30. Il sert surtout à fixer l’ordre de lecture.

30 2 * * * /usr/local/bin/backup-site.sh

Ce deuxième exemple lance une commande toutes les quinze minutes. Le pas régulier est porté par la notation avec barre oblique.

*/15 * * * * /usr/local/bin/check-queue.sh

La subtilité à surveiller concerne les deux champs “jour”. Selon les implémentations, quand jour du mois et jour de semaine sont tous les deux restreints, la logique peut surprendre. Pour éviter les ambiguïtés, écrivez une planification simple quand c’est possible, ou ajoutez un test dans le script exécuté.

Créer, lister et supprimer une crontab utilisateur

Sauvegardez avant de modifier. Cette copie évite les restaurations improvisées, surtout sur un serveur déjà ancien ou partagé.

Pour modifier la crontab de l’utilisateur courant, la commande habituelle est crontab -e. Elle ouvre l’éditeur configuré sur le système et installe la nouvelle version après enregistrement. Pour contrôler ce qui est actif, utilisez crontab -l. Pour supprimer toute la crontab de l’utilisateur, crontab -r existe, mais c’est une commande à manier avec prudence, car elle retire tout le fichier d’un coup.

Pour approfondir ce point, consultez Trouver son adresse IP publique sous Linux, qui traite plus précisément de trouver son adresse ip publique sous linux sans se tromper.

Avant de supprimer, exportez toujours une copie. Le fichier obtenu devient votre point de retour arrière immédiat et vérifiable.

crontab -l > ~/crontab-$(date +%F).bak

Ce geste prend quelques secondes et évite une restauration pénible. En production, la sauvegarde de crontab devrait précéder toute modification importante. Vous pouvez aussi stocker les scripts appelés par cron dans un dépôt, puis ne laisser dans la crontab que les horaires et appels principaux. Cette séparation rend les revues plus simples, car l’horaire reste dans cron tandis que la logique évolue comme du code normal.

Pour modifier la crontab d’un autre utilisateur, l’administrateur peut utiliser crontab -u utilisateur -e. Là encore, le point décisif n’est pas seulement la syntaxe : c’est le contexte d’exécution. Si un script fonctionne en root mais échoue avec un utilisateur applicatif, le problème vient souvent des droits, du répertoire de travail ou des variables d’environnement.

Écrire des commandes cron robustes

Écrivez moins dans la crontab. Mettez la logique dans un script, avec un nom lisible, documenté et versionné.

Un job cron fiable évite les suppositions. Il appelle un script avec un chemin absolu, fixe le répertoire de travail si nécessaire et redirige les sorties. La ligne suivante est plus maintenable qu’une commande longue directement collée dans la crontab :

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 3 * * * cd /srv/app && /usr/local/bin/app-backup.sh >> /var/log/app-backup.log 2>&1

Le script app-backup.sh peut alors gérer la logique, les erreurs et les messages. La crontab reste lisible, et le journal donne une preuve d’exécution. Sans redirection, cron peut envoyer la sortie par mail local selon la configuration. C’est utile sur un serveur préparé pour cela, mais invisible sur beaucoup d’installations modernes où le mail système n’est pas surveillé.

Ajoutez aussi des verrous applicatifs quand une tâche peut durer plus longtemps que son intervalle. Une sauvegarde prévue toutes les heures mais parfois longue de 90 minutes peut se chevaucher et saturer le serveur. Un outil comme flock, ou un verrou géré dans le script, évite ce scénario.

Choisir le bon format : crontab utilisateur ou tâche système

Une crontab utilisateur convient aux automatisations liées à un compte précis : synchronisation de fichiers, exports personnels, scripts applicatifs qui ne demandent pas de privilège global. C’est simple, lisible et rapide à déployer. En revanche, une tâche qui concerne tout le serveur mérite souvent un emplacement système, avec un propriétaire explicite et une convention de déploiement claire, afin que la responsabilité ne dépende pas d’un compte personnel oublié.

Le fichier /etc/crontab et les fichiers dans /etc/cron.d/ ajoutent généralement un champ utilisateur avant la commande. C’est la différence qui piège le plus souvent les copier-coller. Une ligne valide dans une crontab utilisateur peut devenir fausse dans un fichier système si vous ne tenez pas compte de ce champ supplémentaire.

Pour les distributions qui utilisent systemd, les timers systemd deviennent intéressants quand vous voulez une intégration forte avec les unités, les logs via journalctl, les dépendances de service, les reprises après démarrage ou des calendriers plus expressifs. Cron reste excellent pour les tâches simples. Systemd timer devient préférable quand l’exécution fait partie d’un service plus large.

Tester et diagnostiquer une tâche cron qui ne part pas

Changez une seule chose à la fois. Sinon, le diagnostic devient illisible et vous perdez la cause réelle.

Quand un job ne s’exécute pas, ne commencez pas par changer l’horaire au hasard. Reproduisez d’abord la commande dans un environnement proche de cron. Connectez-vous avec l’utilisateur concerné, lancez le script avec son chemin absolu, puis vérifiez les droits, le répertoire courant et les variables nécessaires. Ce test manuel ne prouve pas tout, mais il élimine déjà les erreurs de permission et de chemin les plus évidentes.

La panne la plus fréquente est le PATH incomplet. Une commande disponible dans votre terminal peut être introuvable pour cron. Remplacez donc node, php, mysqldump ou python par leur chemin complet, trouvé avec command -v. La deuxième panne classique vient des chemins relatifs. Un script qui lit ./config.json fonctionne depuis son dossier, mais échoue quand cron le lance depuis un autre répertoire.

Regardez ensuite les journaux du système. Selon la distribution, les traces peuvent se trouver dans /var/log/syslog, /var/log/cron, les mails locaux ou le journal systemd. Si la tâche écrit elle-même un fichier de log, vous gagnez du temps. Un job sans trace est un job difficile à défendre en production.

1. lancer la commande manuellement avec le même utilisateur ;
2. remplacer les binaires par leurs chemins complets ;
3. forcer le répertoire de travail attendu ;
4. rediriger les sorties vers un fichier contrôlé ;
5. attendre le prochain déclenchement avant de modifier une deuxième chose.

# tester le script avec l'utilisateur prévu
sudo -u www-data /usr/local/bin/app-backup.sh

# trouver le chemin réel d'un binaire
command -v mysqldump

Gérer les horaires, fuseaux et changements d’heure

L’heure affichée n’est pas toujours l’heure d’exécution attendue. Posez le fuseau explicitement quand l’enjeu métier l’exige vraiment.

Les planifications horaires ont l’air neutres, mais elles dépendent du fuseau du système ou de la configuration explicitement posée. La variable CRON_TZ, quand elle est supportée par l’implémentation, peut rendre une crontab plus lisible si un serveur en UTC doit exécuter une tâche à une heure métier française. Sans choix clair, un changement d’infrastructure peut déplacer l’exécution d’une heure ou plus, surtout quand plusieurs serveurs, conteneurs ou environnements de staging cohabitent avec des réglages différents.

Le passage à l’heure d’été ou d’hiver mérite aussi une décision. Une tâche prévue à une heure qui disparaît lors du changement d’heure peut ne pas se comporter comme vous l’imaginez. Pour les traitements critiques, préférez une fenêtre robuste : script idempotent, contrôle de date dans l’application, verrou et journal. Cron donne le déclencheur ; le script doit rester capable de décider quoi faire si l’environnement temporel a bougé.

Les jobs mensuels demandent la même prudence. Une ligne prévue le 31 ne s’exécutera pas tous les mois. Si votre besoin est “le dernier jour du mois”, écrivez une tâche quotidienne proche de la fin de mois puis contrôlez la date dans le script, ou utilisez un outil plus adapté. C’est moins élégant dans la crontab, mais plus exact en exploitation.

Sécuriser une crontab en production

Une crontab est un point d’entrée d’exploitation. Traitez-la comme tel, même pour une seule ligne de maintenance nocturne.

Une crontab peut déclencher des actions puissantes : sauvegarder une base, supprimer des fichiers, redémarrer un service, envoyer des données. Elle doit donc être relue comme du code d’exploitation. Limitez les droits de l’utilisateur, évitez les scripts modifiables par n’importe qui et gardez les secrets hors de la ligne crontab. Un mot de passe exposé dans une crontab finit souvent dans un export, un ticket ou une capture d’écran.

Préférez les fichiers de configuration protégés, les variables d’environnement chargées par un wrapper maîtrisé, ou un secret manager si l’infrastructure en dispose. Vérifiez également les permissions des scripts appelés. Si un script exécuté par root est modifiable par un utilisateur non privilégié, vous avez créé une escalade de privilèges potentielle, parfois difficile à repérer parce que la crontab ressemble à une simple ligne de maintenance. La simplicité de cron ne doit pas masquer la puissance des commandes qu’il lance.

Documentez enfin la finalité de chaque job. Une ligne comme 0 4 * * * suivie d’un vieux script mystérieux peut survivre des années. Le jour où elle casse, personne ne sait si elle est encore utile. Un commentaire clair, un propriétaire identifié et un journal suffisent souvent à éviter les automatismes fantômes.

Mettre une crontab sous contrôle au lieu de la laisser dériver

Le vrai problème des crontabs anciennes n’est pas seulement leur syntaxe. C’est leur dérive. Un job ajouté pour dépanner devient permanent, un ancien export continue de tourner, un script renommé laisse une ligne morte, puis personne n’ose supprimer quoi que ce soit parce que l’historique manque. À ce stade, cron fonctionne encore, mais l’exploitation n’est plus maîtrisée et chaque modification devient un pari sur une mémoire collective souvent incomplète.

Pour reprendre la main, faites un inventaire simple. Listez chaque tâche, son propriétaire, son objectif, son script, son journal et son niveau de criticité. Une tâche qui n’a ni propriétaire ni preuve d’utilité doit être surveillée avant suppression, pas effacée brutalement. Ajoutez temporairement un journal plus parlant, vérifiez si elle produit encore une sortie utile, puis décidez.

• À garder : sauvegarde vérifiée, rotation de logs, traitement métier encore utilisé, contrôle de service documenté.
• À corriger : tâche utile mais sans journal, sans verrou, avec chemin relatif ou avec droits trop larges.
• À désactiver prudemment : ancien export, notification obsolète, script non trouvé, job redondant avec un service applicatif.
• À documenter : toute tâche critique dont l’échec doit déclencher une alerte ou une action humaine.

Cette phase évite deux erreurs opposées : conserver indéfiniment des jobs inutiles ou nettoyer trop vite une automatisation qui protège encore le système. Dans une petite infrastructure, une page de documentation suffit. Dans une équipe, rattachez les scripts à un dépôt et nommez un responsable. Une crontab fiable n’est pas figée ; elle est révisée régulièrement.

Les exemples utiles à adapter

Ces exemples ne sont pas des recettes à copier sans test, mais ils donnent une base de lecture. Adaptez les chemins, l’utilisateur et les journaux à votre serveur.

# Tous les jours à 2 h, sauvegarde applicative
0 2 * * * /usr/local/bin/backup-app.sh >> /var/log/backup-app.log 2>&1

# Toutes les 10 minutes, traitement d'une file
*/10 * * * * flock -n /tmp/queue-worker.lock /usr/local/bin/process-queue.sh

# Le lundi à 8 h, rapport hebdomadaire
0 8 * * 1 /usr/local/bin/weekly-report.sh >> /var/log/weekly-report.log 2>&1

Le verrou évite qu’un traitement trop long démarre une deuxième fois. C’est souvent plus sûr qu’un horaire simplement espacé.

Ce qu’il faut retenir avant d’automatiser

Cron est fiable quand la tâche est explicite. Il devient fragile quand la ligne dépend d’un contexte implicite : alias, répertoire courant, variable oubliée, sortie non surveillée, utilisateur mal choisi. Avant de valider une automatisation, demandez-vous si vous pourriez expliquer en une minute quand elle tourne, avec quels droits, où elle écrit et comment elle échoue.

La meilleure crontab reste lisible, testable et réversible. Automatisez les tâches répétitives, mais gardez une trace claire.

Pour approfondir ce point, consultez Clonezilla : Guide complet pour créer une, qui traite plus précisément de clonezilla : guide complet pour créer une image disque sécurisée et chiffrée sous linux ou windows.