Crontab : comprendre et planifier ses tâches
Auteur : Rédaction Domeny.ForSale Publié le
En bref : Crontab est une table qui définit les horaires des commandes exécutées automatiquement par le service cron, le plus souvent sur les systèmes Linux et Unix. Ce nom désigne aussi la commande permettant de gérer cette table. Avec crontab, vous pouvez par exemple effectuer une sauvegarde quotidienne ou lancer un script toutes les quelques minutes, sans vous connecter manuellement au serveur.
Quelle différence entre cron et crontab ?
Cron est un service qui fonctionne en arrière-plan : il consulte les horaires et lance les commandes enregistrées aux moments prévus. Crontab définit cette planification. Une entrée ne suffit pas à elle seule : le service cron doit être installé et démarré, et l’ordinateur ou le serveur doit fonctionner à l’heure prévue.
Chaque utilisateur peut avoir sa propre table crontab. Une tâche s’exécute avec les droits du propriétaire de la table : une entrée ajoutée par un utilisateur ordinaire ne bénéficie donc pas automatiquement des droits d’administrateur. Cette distinction compte aussi bien pour la sécurité que pour l’accès aux fichiers.
Cron convient aux tâches techniques régulières : génération de rapports, synchronisation de données ou suppression de fichiers temporaires. En revanche, il ne réagit pas spontanément à des événements comme la réception d’une commande : il lance les commandes aux horaires définis dans la configuration.
Comment lire une entrée crontab ?
Dans la crontab d’un utilisateur, chaque entrée comprend cinq champs temporels, suivis de la commande :
minute heure jour_du_mois mois jour_de_la_semaine commande
Les champs sont séparés par des espaces ou des tabulations. Le tableau présente leur signification de base :
| Champ | Plage habituelle | Signification de l’astérisque * |
|---|---|---|
| Minute | 0–59 | Chaque minute |
| Heure | 0–23 | Chaque heure |
| Jour du mois | 1–31 | Chaque jour du mois |
| Mois | 1–12 | Chaque mois |
| Jour de la semaine | 0–7, généralement 0 et 7 désignent le dimanche | Chaque jour de la semaine |
Exemple d’entrée :
30 2 * * * /home/anne/bin/backup.sh
Cette entrée lance le script backup.sh tous les jours à 02:30. L’heure est interprétée selon le fuseau horaire utilisé par cron, généralement celui configuré sur le serveur, et non celui de l’ordinateur de la personne qui modifie la planification.
Les virgules, les plages et les pas sont également utiles pour définir les horaires :
0 8 * * 1-5— à 08:00 du lundi au vendredi.0 9,17 * * *— tous les jours à 09:00 et à 17:00.*/15 * * * *— aux minutes 0, 15, 30 et 45 de chaque heure.
Un pas ne définit pas un délai compté à partir de la fin de la tâche. L’entrée */15 lance la commande selon l’horloge, même si l’exécution précédente est encore en cours. De même, */7 dans le champ des minutes ne produit pas des intervalles réguliers de sept minutes tout au long de la journée : après la minute 56 vient la minute 0 de l’heure suivante.
Les champs du jour du mois et du jour de la semaine présentent un piège important. Dans les implémentations courantes, lorsque ces deux champs sont restreints, il suffit que l’une des deux conditions soit remplie. L’entrée 0 9 1 * 1 signifie donc « à 09:00 le premier jour du mois ou le lundi », et non uniquement les lundis qui tombent le premier jour du mois. Consultez la documentation de votre implémentation pour connaître les détails de la syntaxe, généralement avec man 5 crontab.
Comment ajouter et vérifier une tâche ?
Le plus sûr est de commencer par un test sans risque qui écrit la date dans un fichier. Vous pourrez ainsi vérifier la planification indépendamment du fonctionnement du script à utiliser ensuite.
- Ouvrez la table de l’utilisateur courant avec la commande
crontab -e. - Ajoutez l’entrée ci-dessous en adaptant les chemins à votre système.
- Enregistrez le fichier et fermez l’éditeur.
- Après une à deux minutes, vérifiez le fichier de sortie.
* * * * * /usr/bin/date >> /home/anne/cron-test.log 2>&1
L’opérateur >> ajoute le résultat à la fin du fichier au lieu d’en écraser le contenu. La notation 2>&1 redirige les messages d’erreur vers le même fichier. Le répertoire de destination doit exister et l’utilisateur doit disposer du droit d’écriture.
La commande crontab -l affiche les tâches enregistrées. Une fois le test réussi, supprimez la ligne de test avec crontab -e et ajoutez la planification souhaitée. Attention à crontab -r : cette commande supprime toute la table de l’utilisateur, et non une seule entrée.
Ne confondez pas la table de l’utilisateur avec le fichier système /etc/crontab. Dans ce fichier, ainsi que dans les fichiers habituels de /etc/cron.d/, un champ supplémentaire indiquant le nom de l’utilisateur qui exécute la tâche figure entre les champs temporels et la commande.
Pourquoi le script fonctionne-t-il manuellement, mais pas avec cron ?
Cron lance les commandes dans un environnement différent, généralement plus restreint que celui du terminal de l’utilisateur. Il ne faut pas supposer qu’il charge la configuration du shell, dispose des mêmes variables ou démarre dans le répertoire du script.
Pour établir le diagnostic, vérifiez en priorité :
- Les chemins : utilisez des chemins absolus pour les programmes et les fichiers ; si le script nécessite un répertoire de travail précis, définissez-le explicitement.
- Les droits : l’utilisateur qui exécute la tâche doit pouvoir lire les données et écrire le résultat ; un script lancé directement doit disposer du droit d’exécution et d’une ligne correcte indiquant l’interpréteur.
- L’environnement : définissez les variables nécessaires et le bon interpréteur au lieu de vous reposer sur la configuration du terminal.
- Les journaux : enregistrez la sortie et les erreurs de la tâche ; vérifiez aussi l’état du service et les journaux de cron propres à votre système.
Si une tâche risque de durer plus longtemps que l’intervalle entre deux lancements, utilisez un verrou pour empêcher les exécutions simultanées, par exemple avec l’outil flock, s’il est disponible. Cron seul n’assure pas cette protection.
Quand faut-il aller au-delà de crontab ?
Le cron classique ne rattrape généralement pas les tâches manquées pendant que l’ordinateur était éteint. Les changements d’heure peuvent également affecter les exécutions durant les heures concernées ; le comportement exact dépend de l’implémentation. Pour un ordinateur portable ou des tâches qui doivent être rattrapées, envisagez anacron ou un timer systemd configuré à cet effet.
Avant d’ajouter une tâche importante, exécutez sa commande manuellement sous le compte de l’utilisateur prévu, puis vérifiez son exécution par cron en enregistrant les erreurs. Pour les sauvegardes, vérifiez également que les données peuvent être restaurées : le bon déroulement du script ne prouve pas à lui seul que la sauvegarde est exploitable.
À lire aussi : Qu’est-ce que le 2FA ?
À lire aussi
