Aller au contenu
Administration Linux medium

Cron et Crontab : planification de tâches sur Linux

11 min de lecture

Sous Linux, la planification de tâches permet d’automatiser des commandes ou des scripts à des moments précis. L’outil le plus couramment utilisé pour cela s’appelle cron. Grâce à lui, je peux lancer une sauvegarde chaque nuit, vider des fichiers de logs chaque semaine ou encore envoyer un rapport automatiquement chaque mois.

Dans ce guide, je vais détailler son fonctionnement, la syntaxe des crontabs, et vous donner des exemples concrets à adapter à vos propres besoins.

Le service cron tourne en tâche de fond sur la plupart des systèmes Unix/Linux. Il surveille en permanence les fichiers de planification, appelés crontabs, pour exécuter automatiquement des tâches à des heures précises.

Dès qu’on crée ou modifie une crontab, le démon cron l’interprète et s’assure que chaque commande indiquée soit exécutée au bon moment. Pour cela, il se base sur l’horloge système. Inutile de relancer cron après modification : il détecte automatiquement les changements.

Il existe deux types de crontabs :

  • Les crontabs utilisateurs, propres à chaque compte. Chacun peut y définir ses propres tâches.
  • La crontab système, située dans /etc/crontab, qui peut gérer des tâches globales pour tous les utilisateurs. Elle inclut un champ supplémentaire pour indiquer l’utilisateur qui exécutera la tâche.

Par exemple, voici une ligne typique dans /etc/crontab :

Fenêtre de terminal
30 2 * * * root /usr/local/bin/backup.sh

Cela signifie que le script backup.sh sera lancé à 2h30 tous les jours, exécuté par l’utilisateur root.

Enfin, cron lit aussi les fichiers dans des répertoires spécifiques comme /etc/cron.daily/, /etc/cron.hourly/, etc. Tout script placé là sera exécuté à la fréquence associée.

Ce système est léger, fiable et très flexible, ce qui en fait un outil incontournable pour automatiser des tâches récurrentes en administration système.

Pour planifier une tâche avec cron, chaque ligne de la crontab doit respecter une syntaxe précise composée de six champs. Les cinq premiers définissent la date et l’heure d’exécution et le dernier contient la commande à lancer.

Voici la structure générale d’une ligne crontab :

* * * * * commande à exécuter
│ │ │ │ │
│ │ │ │ └── Jour de la semaine (0 - 7) (dimanche = 0 ou 7)
│ │ │ └──── Mois (1 - 12)
│ │ └────── Jour du mois (1 - 31)
│ └──────── Heure (0 - 23)
└────────── Minute (0 - 59)

Par exemple :

Fenêtre de terminal
0 5 * * 1 /usr/bin/apt update

Cette ligne exécute apt update tous les lundis à 5h00 du matin.

  • * : signifie “à chaque valeur possible”. Par exemple, * * * * * signifie toutes les minutes.
  • , : permet de lister plusieurs valeurs. Ex. : 1,15 dans le champ des jours = le 1er et le 15 du mois.
  • - : définit un intervalle. Ex. : 1-5 pour du lundi au vendredi.
  • / : permet de définir une fréquence. Ex. : */2 pour toutes les deux unités.

Certains systèmes acceptent aussi des mots-clés :

Fenêtre de terminal
@reboot # À chaque démarrage de la machine
@daily # Une fois par jour (équivalent à 0 0 * * *)
@weekly # Une fois par semaine (équivalent à 0 0 * * 0)
@monthly # Une fois par mois (équivalent à 0 0 1 * *)

Grâce à cette syntaxe simple mais puissante, on peut configurer des tâches très précises sans script complexe. Il suffit de bien comprendre la logique des champs pour éviter les erreurs de planification.

Pour gérer mes tâches planifiées, j’utilise la commande crontab, qui permet de créer, afficher ou supprimer mes fichiers crontab personnels. Chaque utilisateur possède sa propre crontab, totalement indépendante des autres.

Fenêtre de terminal
crontab -e

Cette commande ouvre l’éditeur de texte défini par l’environnement (vi, nano, etc.). Je peux alors ajouter mes lignes de planification. Une fois le fichier enregistré et fermé, les tâches sont automatiquement prises en compte par cron.

Exemple :

Fenêtre de terminal
30 6 * * * /home/user/scripts/backup.sh

Ce script sera exécuté tous les jours à 6h30.

Fenêtre de terminal
crontab -l

Cela me permet de voir toutes les tâches déjà planifiées pour mon utilisateur.

Fenêtre de terminal
crontab -r

Attention : cette commande supprime toutes les tâches sans confirmation. Pour éviter les accidents, je préfère souvent utiliser :

Fenêtre de terminal
crontab -i -r

Le -i ajoute une confirmation avant suppression.

Le fichier /etc/crontab et les fichiers dans /etc/cron.d/ sont utilisés par le système. Leur syntaxe diffère légèrement, car ils ajoutent un champ pour spécifier l’utilisateur qui exécutera la commande :

Fenêtre de terminal
# Minute Heure Jour Mois JourSemaine Utilisateur Commande
0 1 * * * root /usr/local/sbin/maj_logs.sh

Enfin, pour planifier rapidement sans écrire de crontab, je peux aussi placer mes scripts directement dans :

  • /etc/cron.hourly/
  • /etc/cron.daily/
  • /etc/cron.weekly/
  • /etc/cron.monthly/

Ces répertoires sont lus automatiquement par cron selon une fréquence définie dans le fichier /etc/crontab.

La gestion des crontabs est simple mais demande rigueur : une erreur de syntaxe ou une mauvaise commande peut bloquer une automatisation critique.

Rien ne vaut des cas concrets pour bien comprendre comment utiliser crontab. Voici quelques exemples que j’utilise régulièrement en administration système pour automatiser mes tâches.

Fenêtre de terminal
0 2 * * * /usr/local/bin/sauvegarde.sh

Cette commande lance le script sauvegarde.sh chaque jour à 2h00 du matin. Pratique pour automatiser les copies de données sensibles hors des heures de production.

Fenêtre de terminal
0 4 * * 0 find /var/log -type f -name "*.log" -delete

Chaque dimanche à 4h00, cette commande supprime les fichiers .log du répertoire /var/log. Cela permet de garder un système propre et éviter l’encombrement du disque.

Fenêtre de terminal
30 3 * * 1 apt update && apt upgrade -y

Chaque lundi à 3h30, le système est mis à jour. Cela garantit que les dernières corrections de sécurité sont appliquées régulièrement.

Fenêtre de terminal
*/5 * * * * systemctl is-active apache2 || systemctl restart apache2

Cette ligne vérifie toutes les 5 minutes si le service apache2 est actif. S’il est arrêté, il est automatiquement redémarré. Très utile pour maintenir un service web en ligne sans surveillance manuelle.

Fenêtre de terminal
MAILTO=admin@example.com
0 7 * * * /usr/local/bin/report.sh

Cette configuration envoie le résultat de la commande report.sh par mail chaque matin à 7h00 à l’administrateur. Il suffit que mailutils ou sendmail soit installé et configuré sur le système.

Ces exemples montrent à quel point cron est flexible : en quelques lignes, je peux automatiser la majorité de mes tâches répétitives.

Utiliser cron efficacement, ce n’est pas seulement écrire des lignes dans une crontab. Pour éviter les erreurs et rendre les tâches plus robustes, voici les bonnes pratiques que j’applique systématiquement.

Par défaut, les sorties des tâches cron (stdout et stderr) sont envoyées par mail à l’utilisateur. Pour garder une trace ou éviter les messages inutiles, je redirige les sorties :

Fenêtre de terminal
0 3 * * * /usr/bin/backup.sh > /var/log/backup.log 2>&1
  • > redirige la sortie standard (stdout) vers un fichier.
  • 2>&1 redirige les erreurs (stderr) vers le même fichier.

Cela me permet de consulter les logs de chaque exécution en cas de souci.

Je peux envoyer le résultat d’une tâche par mail automatiquement :

Fenêtre de terminal
MAILTO="admin@example.com"

Si la commande produit une sortie, elle sera envoyée à cette adresse. Très utile pour surveiller les tâches critiques.

Si plusieurs tâches s’exécutent en même temps, cela peut ralentir le système ou causer des conflits (accès à un même fichier, surcharge CPU…). Pour l’éviter :

  • Je répartis les tâches dans le temps (ex. : 2h10, 2h20…).
  • J’utilise des verrous avec flock pour interdire les doubles exécutions :
Fenêtre de terminal
* * * * * /usr/bin/flock -n /tmp/mon_script.lock /usr/local/bin/mon_script.sh

Avant de placer une commande dans la crontab, je la teste manuellement dans le terminal. Cela m’évite de planifier une commande qui échouerait à cause d’un chemin incorrect ou d’un droit insuffisant.

L’environnement cron est souvent minimal. Je préfère toujours indiquer les chemins absolus des scripts et commandes pour éviter toute ambiguïté :

Fenêtre de terminal
/usr/bin/rsync /home/data /mnt/backup

Si vous ne maitrisez pas la commande rsync, je vous invite à consulter le guide sur la sauvegarde avec rsync pour en comprendre les subtilités.

En appliquant ces astuces simples, mes tâches planifiées deviennent plus fiables, plus faciles à diagnostiquer et surtout, je gagne du temps en limitant les erreurs invisibles.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions
5 min.
80%

Informations

  • Le chronomètre démarre au clic sur Démarrer
  • Questions à choix multiples, vrai/faux et réponses courtes
  • Vous pouvez naviguer entre les questions
  • Les résultats détaillés sont affichés à la fin

Lance le quiz et démarre le chronomètre

Grâce à cron, j’ai à disposition un outil simple et efficace pour automatiser mes tâches sur Linux. Que ce soit pour des sauvegardes, des nettoyages ou des vérifications, la planification devient un réflexe incontournable en administration système.

Mais cron n’est pas la seule option. Si je travaille sur un système utilisant systemd, je peux aussi utiliser les systemd timers, une méthode plus moderne et intégrée au système d’init. Elle offre des fonctionnalités supplémentaires comme la dépendance entre services, une meilleure gestion des logs et la possibilité de lancer des tâches à intervalles précis même après un redémarrage.

J’aborde en détail cette autre méthode dans le guide sur les timers systemd, qui peut parfaitement compléter ou remplacer cron selon mes besoins et le contexte.