Cron : planification de tâches sur Linux
Mise à jour :
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.
Fonctionnement de Cron
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
:
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.
Syntaxe de Crontab
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 :
0 5 * * 1 /usr/bin/apt update
Cette ligne exécute apt update
tous les lundis à 5h00 du matin.
Caractères spéciaux utiles
*
: 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.
Abréviations pratiques
Certains systèmes acceptent aussi des mots-clés :
@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.
Gestion des Crontabs
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.
Créer ou modifier une crontab
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 :
30 6 * * * /home/user/scripts/backup.sh
Ce script sera exécuté tous les jours à 6h30.
Afficher les tâches existantes
crontab -l
Cela me permet de voir toutes les tâches déjà planifiées pour mon utilisateur.
Supprimer une crontab
crontab -r
Attention : cette commande supprime toutes les tâches sans confirmation. Pour éviter les accidents, je préfère souvent utiliser :
crontab -i -r
Le -i
ajoute une confirmation avant suppression.
Crontabs système vs utilisateur
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 :
# Minute Heure Jour Mois JourSemaine Utilisateur Commande0 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.
Exemples Pratiques
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.
Sauvegarde automatique de fichiers
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.
Nettoyage des fichiers journaux
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.
Mise à jour automatique des paquets
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.
Surveillance d’un service
*/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.
Notification par e-mail
MAILTO=admin@example.com0 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.
Bonnes Pratiques et Astuces
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.
Redirection des sorties et gestion des erreurs
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 :
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.
Utilisation de MAILTO
Je peux envoyer le résultat d’une tâche par mail automatiquement :
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.
Éviter les conflits et les surcharges
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 :
* * * * * /usr/bin/flock -n /tmp/mon_script.lock /usr/local/bin/mon_script.sh
Tester les commandes avant planification
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.
Spécifier les chemins complets
L’environnement cron est souvent minimal. Je préfère toujours indiquer les chemins absolus des scripts et commandes pour éviter toute ambiguïté :
/usr/bin/rsync /home/data /mnt/backup
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
Tu as suivi tout le guide sur Cron ? Parfait ! C’est maintenant le moment de vérifier ce que tu as retenu. Ce contrôle de connaissances te permet de tester ta compréhension des notions essentielles : syntaxe de crontab, gestion des tâches, planification, redirections et bonnes pratiques.
L’objectif : t’assurer que tu maîtrises suffisamment cron pour l’utiliser sereinement dans ton travail quotidien ou sur ton serveur personnel.
Pourquoi ce contrôle ?
Cet contrôle va vous permettre de valider vos connaissances sur le sujet abordé dans le guide. Il comporte des QCM, des questions vrai/faux et des réponses ouvertes à un mot.
🕒 Le chronomètre commence dès que vous cliquez sur Démarrer le test. Vous devrez terminer l’examen avant la fin du temps imparti.
🎯 Pour réussir, vous devez obtenir au moins 80% de bonnes réponses.
💡 Je ne fournis pas directement les réponses aux questions. Cependant, si certaines sont complexes, des pistes d’explication pourront être proposées dans le guide ou après l’examen.
Bonne chance ! 🚀
- 10 questions aléatoires issues de la banque de questions,
- 5 minutes pour répondre,
- 80 % requis pour réussir.
Ce quiz est une excellente façon de valider tes acquis avant d’automatiser en production.
Conclusion
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.