Sous Linux, cron exécute des commandes à heure fixe, sans que personne ne lance quoi que ce soit. Toute la syntaxe cron Linux tient dans une ligne de cinq champs suivie de la commande. Vous éditez cette ligne avec crontab -e, et le démon s’occupe du reste. La difficulté n’est presque jamais la syntaxe : c’est que la tâche ne part pas, sans le moindre message d’erreur. Ce guide traite les deux, et donne la commande qui reproduit l’environnement de cron pour diagnostiquer en dix secondes.
L’essentiel
Commande clé :crontab -epour éditer,crontab -lpour lister.
Format d’une ligne :minute heure jour_du_mois mois jour_de_semaine commande
Paquet :cron(Debian, Ubuntu) oucronie(Fedora, RHEL, Arch, openSUSE).
Cause n°1 de panne : une tâche cron reçoitPATH=/usr/bin:/bin, pas votrePATHde session.
Alternative moderne : timers systemd, avecOnCalendar=.
Vérifié le 18/09/2026 sur Ubuntu 24.04.4 LTS, cron 3.0pl1-184ubuntu2 et systemd 255. Tableau de vérification des commandes en fin d’article.
Cron, crontab, cron job : que veut dire quoi
Cron est le démon : un programme résident qui se réveille chaque minute et compare l’heure aux tâches déclarées. Crontab désigne deux choses à la fois : le fichier qui contient ces tâches, et la commande qui permet de l’éditer. Un cron job, ou tâche cron, est une ligne de ce fichier. Les timers systemd forment un mécanisme distinct, intégré à systemd, qui rend le même service avec une syntaxe différente.
Le nom vient de la contraction de crontab, elle-même tirée de chrono table, la table des temps, du grec chronos (χρόνος), le temps. D’autres origines circulent, de chronograph à Command Run On, sans qu’aucune soit établie. Cron n’a pas de traduction française consacrée : on parle de planificateur de tâches, et la ligne elle-même s’appelle une tâche planifiée.
Installer cron selon votre distribution
Debian et Ubuntu installent le paquet cron par défaut sur une installation standard. Ailleurs, ce n’est pas acquis : sur Arch, comme sur la plupart des images minimales et des conteneurs, la commande crontab est simplement absente.
| Famille | Paquet | Installation |
|---|---|---|
| Debian, Ubuntu | cron |
sudo apt install cron |
| Fedora, RHEL | cronie |
sudo dnf install cronie |
| Arch | cronie |
sudo pacman -S cronie |
| openSUSE | cronie |
sudo zypper install cronie |
Sur openSUSE, le paquet nommé cron n’est qu’un paquet de transition vers cronie : c’est bien cronie qu’il faut installer. Les références officielles de chaque famille : crontab(5) chez Debian pour Debian et Ubuntu, le projet cronie pour Fedora et RHEL, le paquet cronie d’Arch, et la fiche du paquet cron d’openSUSE.
Le nom de l’unité systemd n’est pas le même partout : cron.service avec le paquet Debian, crond.service avec cronie sur Fedora et RHEL, cronie.service sur Arch. Une commande copiée avec le mauvais nom échoue sur Failed to enable unit, unit cron.service does not exist. Plutôt que de deviner, demandez le nom au système :
# Affiche le nom réel de l'unité sur votre machine
systemctl list-unit-files | grep -E 'cron'
# Puis activez-la avec le nom obtenu — ici celui de Debian et Ubuntu
sudo systemctl enable --now cron.service
La syntaxe d’une ligne crontab
Une ligne se compose de cinq champs de temps, puis de la commande. Les champs sont séparés par des espaces ou des tabulations.
# ┌─────────── minute (0-59)
# │ ┌───────── heure (0-23)
# │ │ ┌─────── jour du mois (1-31)
# │ │ │ ┌───── mois (1-12 ou jan,feb,mar…)
# │ │ │ │ ┌─── jour de la semaine (0-7, 0 et 7 = dimanche, ou sun,mon,tue…)
# │ │ │ │ │
0 3 * * * /usr/local/bin/sauvegarde.sh
Cette ligne lance le script tous les jours à 3 h 00. Les noms de mois et de jours s’écrivent sur trois lettres, en anglais, la casse est indifférente.
| Champ | Valeurs acceptées |
|---|---|
| Minute | 0-59 |
| Heure | 0-23 |
| Jour du mois | 1-31 |
| Mois | 1-12, ou jan à dec |
| Jour de la semaine | 0-7 (0 et 7 = dimanche), ou sun à sat |
Les quatre opérateurs
| Opérateur | Rôle | Exemple | Lecture |
|---|---|---|---|
* |
Toutes les valeurs | * * * * * |
Chaque minute |
, |
Liste | 0 8,12,18 * * * |
À 8 h, 12 h et 18 h |
- |
Plage inclusive | 0 9-17 * * * |
Chaque heure de 9 h à 17 h |
/ |
Pas dans une plage | */15 * * * * |
Toutes les 15 minutes |
Un piège mérite d’être connu : si le jour du mois et le jour de la semaine ne commencent ni l’un ni l’autre par *, cron applique un OU, pas un ET. La ligne 30 4 1,15 * 5 s’exécute le 1er et le 15 de chaque mois, et tous les vendredis.
La formulation compte, car l’implémentation ne teste que le premier caractère du champ. Sa page de manuel donne le contre-exemple : 0 0 */2 * sun ne tourne pas tous les dimanches et tous les jours impairs, mais uniquement les dimanches tombant un jour impair — alors que la norme POSIX voudrait l’inverse. La ligne est acceptée sans le moindre avertissement, et se déclenche simplement bien plus rarement que prévu. Pour obtenir un vrai OU, écrivez les deux champs sans * initial.
Les raccourcis @
| Raccourci | Équivalent 5 champs |
|---|---|
@yearly, @annually |
0 0 1 1 * |
@monthly |
0 0 1 * * |
@weekly |
0 0 * * 0 |
@daily |
0 0 * * * |
@hourly |
0 * * * * |
@midnight |
0 0 * * *, identique à @daily |
@reboot |
Une fois après le démarrage |
@midnight mérite une nuance : la page de manuel de Debian et d’Ubuntu le documente explicitement, celle de cronie ne le mentionne pas. Sur Fedora, RHEL ou Arch, préférez donc @daily.
Exemples courants, prêts à copier
*/5 * * * * /usr/local/bin/script.sh # toutes les 5 minutes
0 */6 * * * /usr/local/bin/sync.sh # toutes les 6 heures
0 8 * * 1-5 /usr/local/bin/rapport.sh # jours ouvrés à 8 h
15 22 * * 0 /usr/local/bin/hebdo.sh # dimanche à 22 h 15
0 0 1 * * /usr/local/bin/mensuel.sh # 1er du mois à minuit
@reboot /usr/local/bin/demarrage.sh # après chaque démarrage
Pour relire une expression que vous n’avez pas écrite, crontab.guru la traduit en français courant. C’est utile, mais cela ne vous dira jamais pourquoi votre tâche ne part pas : les sections suivantes s’en chargent.
Les quatre endroits où une tâche peut vivre
C’est la source de confusion la plus fréquente : la syntaxe change selon l’endroit.
La crontab utilisateur
Elle s’édite avec crontab -e, compte cinq champs, et les tâches tournent sous votre identité. Le fichier ne se modifie jamais à la main : il vit dans /var/spool/cron/crontabs/ sur Debian et Ubuntu, en -rw-------, et crontab en vérifie la syntaxe avant de l’installer. L’emplacement varie selon la distribution, d’où l’intérêt de passer par la commande.
crontab -l # lister la vôtre
crontab -u flo -l # lister celle d'un autre utilisateur (root requis)
crontab -r # tout supprimer, sans confirmation
Le fichier /etc/crontab et le répertoire /etc/cron.d/
Ces tables système comptent six champs : un champ utilisateur s’intercale entre le jour de la semaine et la commande.
# /etc/cron.d/nettoyage — noter le champ « root » en sixième position
0 3 * * * root /usr/local/bin/nettoyage.sh
Les répertoires /etc/cron.daily et consorts
Déposez un script exécutable dans /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly ou /etc/cron.monthly : aucune ligne de syntaxe à écrire.
sudo cp mon-script.sh /etc/cron.daily/mon-script # sans extension
sudo chmod +x /etc/cron.daily/mon-script
Deux conditions, faute de quoi le script est ignoré en silence : il doit être exécutable, et son nom ne doit contenir ni point ni extension. Un fichier nommé mon-script.sh n’est jamais exécuté par run-parts. Vérifiez ce que le système retiendra réellement :
run-parts --test /etc/cron.daily
Qui a le droit de créer une tâche
Les fichiers /etc/cron.allow et /etc/cron.deny filtrent l’accès à la commande crontab. Si cron.allow existe, seuls les comptes qui y figurent sont autorisés ; sinon, si cron.deny existe, tous les comptes sauf ceux qui y figurent.
Quand aucun des deux n’existe, le comportement diffère selon l’implémentation, et c’est une source d’erreur classique :
| Implémentation | Sans cron.allow ni cron.deny |
|---|---|
| Debian, Ubuntu | Tous les utilisateurs peuvent planifier. Sa page de manuel le dit explicitement pour les systèmes Debian standard |
| cronie (Fedora, RHEL, Arch, openSUSE) | Seul le super-utilisateur est autorisé |
Sur une Ubuntu 24.04 où ni l’un ni l’autre n’était présent, un compte ordinaire a bien pu créer sa crontab. Si vous êtes sur Fedora ou Arch et que crontab -e vous est refusé, c’est l’inverse qui s’applique : créez /etc/cron.allow et ajoutez-y le compte concerné.
crontab -e n’ouvre pas l’éditeur que vous attendez
Avec cronie (Fedora, RHEL, Arch), crontab -e suit les variables VISUAL puis EDITOR. Si aucune n’est définie, il retombe sur un éditeur figé à la compilation : le script de configuration du projet retient vi, sauf si la distribution passe l’option --with-editor en construisant le paquet. Sur Debian et Ubuntu, il passe par sensible-editor, qui suit le lien /etc/alternatives/editor — nano dans une installation par défaut. Au premier lancement, Ubuntu vous demande de choisir.
# Forcer l'éditeur, le temps d'une commande
EDITOR=nano crontab -e
# Le changer durablement sur Debian et Ubuntu
select-editor
Si vous quittez vi sans savoir en sortir, la crontab reste inchangée : rien n’est cassé.
Les variables d’environnement
| Variable | Rôle | Valeur par défaut |
|---|---|---|
SHELL |
Interpréteur utilisé | /bin/sh |
PATH |
Chemins de recherche | /usr/bin:/bin (mesuré, voir ci-dessous) |
MAILTO |
Destinataire des sorties | Propriétaire de la crontab |
CRON_TZ |
Fuseau horaire de la table | cronie uniquement, voir la FAQ |
Le PATH réduit est la première cause de tâche silencieuse. Un dump complet de l’environnement d’une tâche, exécuté sur le banc de test, donne ceci :
HOME=/root
LOGNAME=root
PATH=/usr/bin:/bin
LANG=C.UTF-8
SHELL=/bin/sh
PWD=/root
Ce n’est pas le PATH de votre session. Une commande installée dans /usr/local/bin, /opt ou /snap/bin reste introuvable. Le démon avait pourtant, lui, un PATH complet : cron impose cette valeur aux tâches, quoi qu’il arrive.
Une précision qui change le diagnostic. On lit souvent que cron n’aurait « aucun PATH par défaut ». C’est inexact, et la nuance compte : le PATH existe, il est seulement réduit à deux répertoires. Résultat, une commande sur deux fonctionne sans chemin absolu, ce qui rend la panne déroutante. La contre-épreuve tient en deux lignes :
* * * * * touch /tmp/temoin.txt # fonctionne : touch vit dans /usr/bin
* * * * * mon-outil # échoue : /usr/local/bin est hors du PATH
Sur le banc de test, la première ligne a bien créé son fichier sans chemin absolu ; la seconde n’a rien produit. Deux réponses : écrire les chemins en absolu, ou déclarer un PATH en tête de crontab.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=""
0 3 * * * /usr/local/bin/sauvegarde.sh
MAILTO="" coupe l’envoi des courriels. Sans cette ligne, chaque sortie produite par une tâche génère un message local — que personne ne lit jamais, et qui masque les erreurs.
Tester une tâche sans attendre l’heure
C’est la question qui revient le plus sur les forums : le script marche dans le terminal, et ne fait rien depuis cron. La raison est presque toujours l’environnement. Plutôt que de modifier l’heure de la tâche pour la voir passer, reproduisez l’environnement de cron et lancez la commande dedans :
env -i SHELL=/bin/sh PATH=/usr/bin:/bin HOME="$HOME" LOGNAME="$USER" \
/bin/sh -c '/usr/local/bin/mon-script.sh'
env -i vide l’environnement avant d’appliquer les quatre variables que cron fournit. Si la commande échoue ici et réussit dans votre terminal, le problème est bien l’environnement, et non la ligne de planification. Le message d’erreur que vous obtenez enfin est celui que cron avalait.
Pour une tâche déclarée dans /etc/cron.daily, l’équivalent consiste à exécuter le script directement en root, puis à vérifier que run-parts --test le retient.
Les logs de cron : où sont vraiment les journaux
Beaucoup de guides renvoient vers /var/log/syslog ou /var/log/cron.log. Sur un système récent, ces fichiers n’existent pas forcément : ils supposent rsyslog installé, ce qui n’est plus systématique. Sur le banc Ubuntu 24.04 utilisé pour cet article, ni l’un ni l’autre n’était présent, et /var/log ne contenait que journal.
# La méthode qui marche partout où systemd tourne
journalctl -u cron --since today # Debian, Ubuntu
journalctl -u crond --since today # Fedora, RHEL
journalctl -u cronie --since today # Arch
# Vérifier si un fichier texte existe quand même sur votre machine
ls -l /var/log/syslog /var/log/cron.log 2>/dev/null
La manipulation souvent recommandée — décommenter la ligne cron.* dans /etc/rsyslog.d/50-default.conf pour obtenir un /var/log/cron.log dédié — suppose rsyslog installé. Sur le banc Ubuntu 24.04, ce fichier de configuration n’existait pas davantage que le répertoire qui le contient. Vérifiez avant de chercher : ls /etc/rsyslog.d/.
Attention au piège : journalctl -u cron sur une Fedora ne renvoie pas d’erreur, il renvoie un journal vide. On en conclut à tort que le démon ne s’est jamais déclenché.
Le journal montre le déclenchement de la tâche par cron, pas ce que le script a écrit. Pour cela, redirigez explicitement la sortie vers un fichier.
Changement d’heure : ce que cron fait réellement
Une idée fausse circule largement, y compris sur les pages les mieux positionnées et sur Wikipédia : au passage à l’heure d’été, les tâches prévues dans l’heure sautée seraient perdues ; au passage à l’heure d’hiver, elles s’exécuteraient deux fois. La documentation officielle dit exactement l’inverse.
La page cron(8) de Debian énonce que si l’horloge avance, les tâches qui auraient dû tourner pendant l’intervalle sauté sont exécutées peu après le changement ; et que si l’horloge recule de moins de trois heures, les tâches tombant dans l’intervalle répété ne sont pas relancées. La page cron(8) de cronie dit la même chose, dans d’autres termes : les tâches sautées sont exécutées immédiatement, et des précautions sont prises pour éviter de les exécuter deux fois.
Le binaire confirme cette gestion active : il contient les messages DST begins, DST ends et clock jumped.
Vérifié par l’exécution, pas seulement par la documentation. Le démon a été lancé sous une horloge simulée avec libfaketime, à raison de soixante minutes simulées par minute réelle, de part et d’autre des deux bascules françaises de 2027. La tâche témoin était planifiée à 2 h 30 : c’est exactement l’heure qui disparaît au printemps et qui se produit deux fois à l’automne.
| Bascule | Ce que devient 2 h 30 | Exécutions constatées |
|---|---|---|
| 28 mars 2027, l’heure avance | N’existe pas ce jour-là | 1 — la tâche est rattrapée |
| 31 octobre 2027, l’heure recule | Se produit deux fois | 1 — aucune double exécution |
L’idée reçue est donc fausse dans les deux sens, et le comportement documenté est bien le comportement réel.
Deux réserves, elles aussi documentées. Cette protection ne vaut que pour les tâches à heure fixe, celles qui n’ont ni * ni intervalle dans les champs heure et minute : une ligne */10 * * * * suit simplement la nouvelle heure. Et un décalage supérieur à trois heures est traité comme une correction d’horloge, appliquée immédiatement sans rattrapage.
En pratique, si l’exactitude horaire compte, réglez le serveur en UTC. Le problème disparaît à la racine.
Quand /etc/cron.daily s’exécute vraiment
Rarement à minuit, contrairement à l’intuition. Sur Debian et Ubuntu, /etc/crontab déclenche cron.daily à 6 h 25, cron.weekly le dimanche à 6 h 47 et cron.monthly le 1er à 6 h 52 — mais seulement si anacron n’est pas installé, comme le montre le test test -x /usr/sbin/anacron présent sur chacune de ces lignes. Quant à cron.hourly, il ne part pas à l’heure pile mais à la minute 17, via la ligne 17 * * * *.
# Les heures réelles sur VOTRE machine
grep 'cron\.' /etc/crontab
cat /etc/anacrontab 2>/dev/null
Si anacron est installé, c’est lui qui prend la main, avec un délai aléatoire et une plage horaire définis dans /etc/anacrontab. Son intérêt : il rattrape les tâches manquées pendant une extinction, ce que cron seul ne sait pas faire. C’est le mécanisme qui rend les postes de bureau utilisables sans serveur allumé en permanence.
Les timers systemd, l’alternative moderne
Un timer systemd se compose de deux fichiers : un .service qui décrit quoi lancer, un .timer qui décrit quand. Sans directive Unit=, systemd active le service portant le même nom.
# /etc/systemd/system/nettoyage.service
[Unit]
Description=Nettoyage hebdomadaire du disque
[Service]
Type=oneshot
ExecStart=/usr/local/bin/nettoyage.sh
# /etc/systemd/system/nettoyage.timer
[Timer]
OnCalendar=Sun *-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
sudo systemctl daemon-reload
sudo systemctl enable --now nettoyage.timer
systemctl list-timers # prochaine exécution de chaque timer
Persistent=true rattrape les exécutions manquées : si la machine était éteinte à l’heure prévue, la tâche part au démarrage suivant. Sa valeur par défaut est false, et elle n’agit que sur les timers déclarés avec OnCalendar=. Côté cron, seul anacron offre cela, et uniquement pour les répertoires cron.daily et suivants.
Traduire une ligne cron en OnCalendar
Les deux syntaxes sont incompatibles : coller une ligne cron dans un timer produit une erreur de parsing. Voici les équivalences, chacune validée par systemd-analyze calendar.
| Ligne cron | OnCalendar= |
Forme normalisée par systemd |
|---|---|---|
0 3 * * * |
*-*-* 03:00:00 |
*-*-* 03:00:00 |
*/15 * * * * |
*-*-* *:00/15 |
*-*-* *:00/15:00 |
0 * * * * |
hourly |
*-*-* *:00:00 |
0 0 * * * |
daily |
*-*-* 00:00:00 |
0 0 1 * * |
monthly |
*-*-01 00:00:00 |
0 0 * * 0 |
Sun *-*-* 00:00:00 |
Sun *-*-* 00:00:00 |
30 4 1,15 * * |
*-*-1,15 04:30:00 |
*-*-01,15 04:30:00 |
*/15 9-17 * * 1-5 |
Mon..Fri *-*-* 09..17:00/15 |
Mon..Fri *-*-* 09..17:00/15:00 |
Attention à weekly. Le raccourci systemd weekly se normalise en Mon *-*-* 00:00:00, soit le lundi, alors que @weekly en cron vaut 0 0 * * 0, soit le dimanche. Les deux raccourcis portent le même nom et ne tombent pas le même jour. Pour reproduire exactement @weekly, écrivez Sun *-*-* 00:00:00.
Testez toujours une expression avant de la mettre en service. Contrairement à cron, systemd fournit son propre validateur :
systemd-analyze calendar "Mon..Fri *-*-* 09..17:00/15"
Cron Linux ou timer systemd : lequel choisir
| Critère | Cron | Timer systemd |
|---|---|---|
| Déclaration | Une ligne | Deux fichiers |
| Journalisation | Courriel via MAILTO |
journalctl -u nom.service |
| Rattrapage après extinction | Non, sauf anacron installé à part | Oui, avec Persistent=true |
| Dépendances entre services | Non | Oui, via les directives [Unit] |
| Test de l’expression | Aucun outil natif | systemd-analyze calendar |
| Portabilité hors Linux | Oui, tout Unix | Non |
Pour une commande isolée, cron reste plus rapide à écrire, et il fonctionne sur tous les Unix. Dès qu’une tâche doit être journalisée, rattrapée ou ordonnée par rapport à un autre service, le timer prend l’avantage.
Diagnostiquer une tâche qui ne se lance pas
Dans l’ordre, du plus fréquent au plus rare.
- Le
PATH. Reproduisez l’environnement avec la commandeenv -idonnée plus haut. C’est le test qui tranche. - Le démon est arrêté.
systemctl status cron, en adaptant le nom de l’unité. - Le
%n’est pas échappé. Dans une crontab,%devient un saut de ligne, et tout ce qui suit le premier%part sur l’entrée standard de la commande. Une redirection écrite après un%est donc avalée elle aussi :date +%Y >> /tmp/log.txtne crée jamais le fichier. Échappez chaque%:date +\%Y. - Le script n’est pas exécutable, ou son shebang manque.
ls -lpuishead -1. - Le mauvais utilisateur. Une ligne de
/etc/cron.d/sans champ utilisateur, ou une tâche qui écrit dans un répertoire appartenant à un autre compte. - Les journaux, en dernier recours, avec le bon nom d’unité.
Pour un exemple de bout en bout, avec script, journalisation et rotation, voyez comment automatiser vos sauvegardes avec rsync et cron.
Cas pratique : un nettoyage hebdomadaire
Avertissement. Le script ci-dessous supprime des fichiers sans confirmation. Remplacez
-deletepar
# /etc/cron.d/purge-vartmp — six champs, l'utilisateur est explicite
0 3 * * 0 root /usr/bin/find /var/tmp -type f -mtime +30 -delete
Ce nettoyage passe par une crontab système, et non par crontab -e, pour une raison précise : /var/tmp porte le sticky bit (drwxrwxrwt). Un utilisateur ordinaire n’y supprime que ses propres fichiers. Lancée depuis une crontab utilisateur, la commande produirait une série de Operation not permitted — invisibles si vous avez suivi le conseil MAILTO="" donné plus haut.
Ce nettoyage ne règle qu’un cas parmi d’autres. Pour un tri complet, la démarche de fond consiste à libérer de l’espace disque en identifiant d’abord ce qui occupe le volume.
Erreurs courantes
errors in crontab file, can't install.
La ligne précédente du message nomme précisément le champ fautif. La crontab en place n’est pas écrasée : rien n’est perdu. Voici la correspondance exacte, relevée sur le banc :
| Message | Cause réelle | Exemple qui le produit |
|---|---|---|
bad minute |
Minute hors de 0-59 | 60 4 * * * |
bad hour |
Heure hors de 0-23 | 0 24 * * * |
bad day-of-month |
Jour hors de 1-31 | 0 0 0 * * |
bad month |
Mois hors de 1-12, ou nom de mois invalide | 0 4 * janvier * |
bad day-of-week |
Jour hors de 0-7, ou nom de jour invalide | 0 4 * * lundi, 0 4 * * sunday |
bad time specifier |
Uniquement un raccourci @ inconnu |
@dayly, @nimportequoi |
Deux pièges dans ce tableau. Les noms de jours s’écrivent sur trois lettres en anglais : sunday en toutes lettres est refusé, sun passe. Et bad time specifier ne concerne jamais un nom de jour : si vous obtenez ce message, regardez votre @, pas vos champs.
crontab: command not found
Le paquet n’est pas installé : reportez-vous au tableau d’installation plus haut.
Failed to enable unit, unit cron.service does not exist.
Le nom de l’unité ne correspond pas à votre distribution. Retrouvez-le avec systemctl list-unit-files | grep cron.
La tâche ne produit rien, sans erreur.
Symptôme typique du PATH ou du % non échappé. Passez directement au test env -i : il produit le message d’erreur que cron gardait pour lui.
Désactiver une tâche sans la supprimer
Commentez la ligne avec un # en tête, dans crontab -e. La planification reste lisible, prête à être réactivée. Évitez de vider la commande ou de la remplacer par :, qui laisse cron se déclencher pour rien chaque fois. Et méfiez-vous de crontab -r, qui efface tout sans confirmation : prenez une copie avant toute manipulation.
crontab -l > ~/crontab-sauvegarde-$(date +\%F).txt
Comment ces commandes ont été vérifiées
| Élément | Niveau | Vérification |
|---|---|---|
Syntaxe 5 champs, opérateurs * , - / |
Testé | Installation réelle via crontab fichier, relecture par crontab -l |
Raccourcis @ (dont @midnight) |
Testé | Chaque raccourci installé un par un ; tous acceptés |
PATH=/usr/bin:/bin d’une tâche |
Testé | Tâche /usr/bin/env exécutée par le démon, environnement complet capturé, alors que le démon avait un PATH complet |
Les six messages bad … et leurs causes |
Testé | Dix lignes fautives installées une par une, message exact relevé pour chacune ; bad time specifier obtenu uniquement sur un @ invalide |
Limitation du OU sur un champ commençant par * |
Testé | 0 0 */2 * sun accepté sans avertissement ; comportement documenté dans la section LIMITATIONS de crontab(5) Debian |
% non échappé avale la redirection |
Testé | Contre-épreuve : date +%Y >> fichier ne crée rien, date +\%Y >> fichier écrit 2026 |
Commande env -i de diagnostic |
Testé | Exécutée avec le PATH de cron ; reproduit bien l’absence des chemins hors /usr/bin et /bin |
Le PATH de cron est réduit, pas absent |
Testé | Contre-épreuve : touch sans chemin absolu s’exécute depuis cron, un binaire de /usr/local/bin appelé de la même façon ne s’exécute pas |
Absence de /etc/rsyslog.d/50-default.conf |
Testé | Ni le fichier ni le répertoire /etc/rsyslog.d ne sont présents sur le banc |
Emplacement /var/spool/cron/crontabs/ |
Testé | Fichier créé et relu après crontab, permissions -rw------- constatées |
Accès crontab sans cron.allow ni cron.deny |
Testé | Contre-épreuve : compte non privilégié créé, crontab installée avec succès. L’écart avec cronie provient de crontab(1) des deux implémentations, qui énoncent des règles opposées |
run-parts ignore les noms à extension |
Testé | run-parts --test sur un répertoire témoin : mon-script.sh écarté, mon-script retenu |
Absence de /var/log/syslog |
Testé | Constaté sur le banc, rsyslog non installé. Le fichier peut exister ailleurs, d’où la commande de vérification |
Équivalences OnCalendar= du tableau |
Testé | systemd-analyze calendar sur les 8 expressions, formes normalisées relevées |
weekly systemd = lundi |
Testé | systemd-analyze calendar weekly |
Unités .timer et .service de l’article |
Testé | systemd-analyze verify sans erreur ; contre-épreuve sur une directive fausse |
Éditeur de crontab -e sur Ubuntu |
Testé | sensible-editor présent, /etc/alternatives/editor pointant sur /bin/nano |
| Éditeur de repli de cronie | Conforme à la documentation | crontab(1) cronie pour VISUAL puis EDITOR ; le configure.ac du projet définit la macro EDITOR sur vi via AC_PATH_PROG, avec repli /usr/bin/vi, sauf option --with-editor au paquetage |
| Comportement au changement d’heure | Testé | Démon lancé sous libfaketime à 60 fois la vitesse réelle, de part et d’autre des bascules du 28/03/2027 et du 31/10/2027. Tâche témoin à 2 h 30 : une exécution dans chaque cas, donc rattrapage au printemps et aucune double exécution à l’automne. Concorde avec cron(8) Debian et cron(8) cronie |
CRON_TZ absent du cron Debian/Ubuntu |
Testé | La chaîne CRON_TZ n’existe pas dans le binaire /usr/sbin/cron du banc ; confirmé par crontab(5) Debian |
Persistent=true |
Conforme à la documentation | systemd.timer(5) ; non reproductible sur le banc, qui ne redémarre pas |
| Noms de paquets par distribution | Conforme à la documentation | Dépôts officiels Arch et openSUSE consultés le 18/09/2026 |
| Noms d’unités systemd par distribution | Conforme à la documentation | cron.service relevé dans le paquet Debian du banc ; cronie.service dans la liste de fichiers du paquet Arch ; crond.service dans l’unité fournie par le projet cronie. Non vérifié pour openSUSE, d’où la commande de détection |
| Étymologie de « cron » | Variable | Plusieurs origines coexistent dans les sources ; aucune n’est établie |
Banc de test : Ubuntu 24.04.4 LTS, cron 3.0pl1-184ubuntu2, systemd 255, libfaketime pour les bascules horaires.
Questions fréquentes
Comment savoir si crontab fonctionne ?
Trois contrôles dans l’ordre : systemctl status cron pour le démon, crontab -l pour vérifier que votre ligne est bien enregistrée, puis journalctl -u cron --since today pour voir les déclenchements réels. Si le démon tourne et que la ligne apparaît, le problème vient de la commande elle-même : testez-la avec env -i.
Comment lister les tâches cron déjà déclarées ?
crontab -l affiche votre crontab utilisateur, et crontab -u nom -l celle d’un autre compte si vous êtes root. Les tâches système se lisent séparément, dans /etc/crontab, dans /etc/cron.d/ et dans les répertoires /etc/cron.*.
Où se trouve le fichier crontab d’un utilisateur ?
Dans /var/spool/cron/crontabs/ sur Debian et Ubuntu, /var/spool/cron/ sur Fedora et Arch. Ne l’éditez pas directement : crontab -e valide la syntaxe avant d’enregistrer, ce qu’une modification manuelle ne fait pas.
Comment exécuter une tâche cron manuellement, pour la tester ?
Reproduisez l’environnement de cron avec env -i SHELL=/bin/sh PATH=/usr/bin:/bin HOME="$HOME" LOGNAME="$USER" /bin/sh -c 'votre-commande'. Lancer simplement la commande dans votre terminal ne prouve rien, puisque votre PATH y est bien plus large.
Comment changer le fuseau horaire d’une tâche cron ?
Avec cronie (Fedora, RHEL, Arch, openSUSE), déclarez CRON_TZ=Europe/Paris en tête de crontab. Avec le cron de Debian et d’Ubuntu, c’est impossible : il ne gère pas les fuseaux par table, et sa page de manuel indique qu’il ne prend pas en charge les fuseaux horaires par utilisateur. La variable y est acceptée sans erreur, puis ignorée. Sur ces distributions, exprimez vos heures dans le fuseau du système, ou gérez la conversion à l’intérieur du script.
Cron et les timers systemd peuvent-ils coexister ? Oui, sans conflit : ce sont deux mécanismes indépendants. Veillez seulement à ne pas déclarer deux fois la même tâche, une fois dans chaque système.
Conclusion
Pour une commande isolée à heure fixe, cron Linux reste le choix le plus direct : une ligne, cinq champs, et crontab -e. Basculez vers un timer systemd dès que vous avez besoin de journaux consultables, d’un rattrapage après extinction, ou d’un ordre entre plusieurs services. Le tableau d’équivalence permet de traduire une planification existante sans la réécrire de zéro.
Quand une tâche ne part pas, ne modifiez pas son heure pour la voir passer : reproduisez l’environnement de cron avec env -i et lancez la commande dedans. Dans la grande majorité des cas, le PATH réduit ou un % non échappé apparaît immédiatement. Pour aller plus loin, la mise en place d’une sauvegarde automatisée constitue le cas d’usage le plus courant, et si vos tâches au démarrage vous préoccupent, la réduction du temps de démarrage traite l’ordonnancement des services.
