Comment afficher et lister les tâches Cron à l’aide de Crontab

La commande crontab est l’interface principale pour afficher, modifier et gérer les tâches planifiées dans le système cron Unix. Pour lister tous les jobs cron de l’utilisateur actuellement connecté, exécutez crontab -l dans n’importe quel terminal. Pour les jobs root ou système, inspectez directement /etc/crontab, /etc/cron.d/ et /var/spool/cron/crontabs/.

Cron est l’épine dorsale de l’automatisation des tâches sur Linux et les systèmes de type Unix. Que vous exécutiez des sauvegardes nocturnes de bases de données sur un environnement VPS Hosting, que vous fassiez la rotation des logs sur un Serveur Dédié, ou que vous renouveliez automatiquement des Certificats SSL via Certbot, comprendre comment auditer et lister chaque tâche planifiée sur une machine est une compétence d’administrateur système incontournable. Ce guide couvre chaque couche de la pile cron — crontabs utilisateur, crontabs système, répertoires drop-in et le spool — ainsi que les pièges réels qui font trébucher même les ingénieurs expérimentés.

Qu’est-ce que Crontab et comment fonctionne le système Cron

Crontab (abréviation de « cron table ») est un fichier de configuration par utilisateur qui indique au démon crond quelles commandes exécuter et quand. Chaque compte utilisateur sur un système — y compris root — peut maintenir un crontab indépendant. Le démon lit ces fichiers au démarrage et après toute modification, puis distribue les jobs selon leurs spécifications temporelles.

L’écosystème cron sur une distribution Linux moderne se compose de plusieurs couches distinctes :

• Crontabs utilisateur — gérés via crontab -e et stockés dans /var/spool/cron/crontabs/ (Debian/Ubuntu) ou /var/spool/cron/ (RHEL/CentOS)
• Crontab système — le fichier /etc/crontab, qui inclut un champ user supplémentaire par entrée
• Répertoire drop-in — /etc/cron.d/, où les paquets installent leurs propres définitions de jobs
• Répertoires run-parts — /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/, qui contiennent des scripts exécutables plutôt que des fichiers au format crontab
• Anacron — un complément à cron qui gère les jobs sur les machines qui ne fonctionnent pas 24h/24 et 7j/7, en lisant depuis /etc/anacrontab

Comprendre dans quelle couche se trouve un job est essentiel lors de l’audit d’un serveur, car crontab -l seul manquera la majorité des tâches planifiées sur un système de production typique.

Syntaxe des champs de temps Crontab

Chaque entrée crontab suit une spécification temporelle fixe à cinq champs avant la commande :

* * * * *  command_to_execute
| | | | |
| | | | +----- day of the week  (0–7, Sunday = 0 or 7)
| | | +------- month            (1–12)
| | +--------- day of the month (1–31)
| +----------- hour             (0–23)
+------------- minute           (0–59)

Raccourcis de syntaxe spéciaux pris en charge par la plupart des implémentations cron :

Les fichiers /etc/crontab et /etc/cron.d/ ajoutent un sixième champ — le nom d’utilisateur sous lequel la commande s’exécute — entre la spécification temporelle et la commande elle-même.

Comment lister les jobs Cron : toutes les méthodes expliquées

1. Afficher ses propres jobs Cron utilisateur

crontab -l

Cela affiche le crontab de l’utilisateur qui exécute la commande. Si aucun crontab n’existe encore, vous verrez soit une sortie vide, soit le message no crontab for <username> — les deux sont normaux.

Exemple de sortie :

# m  h   dom mon dow  command
0    0   *   *   *    /home/deploy/backup.sh
30   2   *   *   7    /home/deploy/scripts/cleanup.sh
15   */4 *   *   *    /usr/local/bin/health-check.sh >> /var/log/health.log 2>&1

Dans cet exemple :

backup.sh s’exécute chaque jour à minuit
cleanup.sh s’exécute chaque dimanche à 02:30
health-check.sh s’exécute toutes les quatre heures à partir de 00:15, avec stdout et stderr redirigés vers un fichier journal

Piège : La redirection de sortie (>>, 2>&1) est fréquemment omise dans les entrées crontab. Sans elle, cron tente d’envoyer la sortie par e-mail à l’utilisateur local via sendmail. Sur les serveurs sans agent de transfert de courrier, cela supprime silencieusement toute sortie et rend le débogage presque impossible. Redirigez toujours la sortie ou définissez MAILTO="" en haut du crontab.
2. Lister les jobs Cron d’un autre utilisateur
Avec sudo ou un accès root, vous pouvez inspecter le crontab de n’importe quel utilisateur :
sudo crontab -l -u john
Remplacez john par le nom d’utilisateur cible. C’est fonctionnellement identique à la lecture du fichier spool brut, mais utilise le mécanisme de verrouillage approprié, il est donc toujours préférable à l’accès direct aux fichiers.
3. Lister tous les crontabs utilisateur en une seule fois
Sur un serveur multi-utilisateurs, itérer sur chaque compte est le seul moyen fiable d’obtenir une vue complète :
for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== Crontab for: $user ==="
    sudo crontab -l -u "$user" 2>/dev/null
done
Le 2>/dev/null supprime les messages « no crontab for » pour les utilisateurs qui n’en ont pas, gardant la sortie propre.
4. Afficher le crontab système
cat /etc/crontab
Une sortie typique sur un système basé sur Debian :
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m  h  dom mon dow  user     command
17  *  *   *   *    root     cd / && run-parts --report /etc/cron.hourly
25  6  *   *   *    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47  6  *   *   7    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52  6  1   *   *    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
Remarquez la protection test -x /usr/sbin/anacron : si anacron est installé, ces appels run-parts sont ignorés et anacron prend en charge les jobs quotidiens, hebdomadaires et mensuels. C’est une source courante de confusion lorsque les jobs semblent ne pas s’exécuter selon le calendrier prévu.
5. Lister les jobs dans /etc/cron.d/
ls -la /etc/cron.d/
Pour inspecter le contenu de chaque fichier du répertoire en une seule passe :
grep -v '^#|^$' /etc/cron.d/*
Cela supprime les lignes de commentaires et les lignes vides, n’affichant que les définitions de jobs actifs. Les gestionnaires de paquets déposent fréquemment des fichiers ici — des exemples courants incluent sysstat, les remplacements logrotate et les agents de surveillance.
6. Inspecter directement le répertoire spool de Cron
ls -la /var/spool/cron/crontabs/
Sur RHEL, CentOS et Fedora, le chemin est /var/spool/cron/ sans le sous-répertoire crontabs. Pour lire le fichier spool brut d’un utilisateur spécifique :
sudo cat /var/spool/cron/crontabs/username
Important : Ne modifiez jamais les fichiers spool directement avec un éditeur de texte. La commande crontab -e utilise le verrouillage de fichiers et valide la syntaxe avant d’installer le nouveau fichier. Les modifications directes peuvent corrompre le fichier ou le laisser dans un état où crond l’ignore entièrement.
7. Lister les jobs Anacron
Si le système utilise anacron pour une planification résiliente :
cat /etc/anacrontab
Les entrées Anacron utilisent une syntaxe différente — période en jours, délai en minutes, identifiant de job et commande — plutôt que le format cron standard à cinq champs.
8. Vérifier les timers Systemd (alternative moderne)
Sur les distributions basées sur systemd, de nombreuses tâches historiquement gérées par cron sont désormais gérées par les timers systemd. Ceux-ci n’apparaîtront dans aucune liste crontab :
systemctl list-timers --all
Un audit complet du serveur doit inclure à la fois les vérifications cron et des timers systemd. Ne pas le faire est l’une des lacunes les plus courantes dans les revues de sécurité et de conformité.
Audit Cron complet : commande en une seule passe
Pour un audit rapide et complet de chaque tâche planifiée sur un système, combinez toutes les sources :
echo "=== /etc/crontab ===" && cat /etc/crontab
echo "=== /etc/cron.d/ ===" && ls /etc/cron.d/ && grep -rh '' /etc/cron.d/
echo "=== User crontabs ===" && for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null && echo "  ^ user: $u"; done
echo "=== Systemd timers ===" && systemctl list-timers --all --no-pager
Modifier et gérer les jobs Cron
Pour ouvrir votre propre crontab dans l’éditeur par défaut du système ($VISUAL ou $EDITOR, avec repli sur vi) :
crontab -e
Pour modifier le crontab d’un autre utilisateur en tant que root :
sudo crontab -e -u username
Pour supprimer tous les jobs cron de l’utilisateur actuel (à utiliser avec précaution — c’est irréversible sans sauvegarde) :
crontab -r
Pour sauvegarder un crontab avant d’effectuer des modifications :
crontab -l > ~/crontab_backup_$(date +%F).txt
Sauvegardez toujours avant de modifier. Il n’y a pas d’annulation intégrée dans crontab -e.
Cron vs. Timers Systemd : comparaison des fonctionnalités




Fonctionnalité
Cron
Timers Systemd




Format de configuration
Texte brut, syntaxe à cinq champs
Fichiers unit (.timer + .service)


Planification par utilisateur
Oui, via les crontabs utilisateur
Oui, via les instances systemd au niveau utilisateur


Gestion des jobs manqués
Non (le job est ignoré si le système est éteint)
Oui, avec Persistent=true


Journalisation
Syslog / mail
Journald (interrogeable avec journalctl)


Gestion des dépendances
Aucune
Graphe de dépendances systemd complet


Délai aléatoire
Non natif (nécessite sleep $RANDOM)
RandomizedDelaySec=


Complexité
Faible
Modérée


Disponibilité
Tous les systèmes Unix/Linux
Linux basé sur systemd uniquement




Pour une automatisation simple basée sur le temps sur n’importe quel système Unix — y compris les environnements legacy et les conteneurs — cron reste le choix le plus portable et le plus simple sur le plan opérationnel. Les timers systemd sont supérieurs lorsque vous avez besoin d’un ordonnancement des dépendances, d’une exécution fiable des jobs manqués ou d’une sortie de journal structurée.
Commandes de liste Crontab courantes : référence rapide




Objectif
Commande




Lister les jobs de l’utilisateur actuel
crontab -l


Lister les jobs d’un autre utilisateur
sudo crontab -l -u username


Lister les jobs de tous les utilisateurs
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null; done


Afficher le crontab système
cat /etc/crontab


Lister les jobs cron.d
ls /etc/cron.d/


Afficher le répertoire spool
ls /var/spool/cron/crontabs/


Afficher les jobs anacron
cat /etc/anacrontab


Lister les timers systemd
systemctl list-timers --all


Modifier le crontab de l’utilisateur actuel
crontab -e


Supprimer le crontab de l’utilisateur actuel
crontab -r




Pièges réels et cas limites
Les variables d’environnement ne sont pas héritées. Cron exécute les jobs dans un environnement shell minimal. Les variables comme PATH, HOME et LANG définies dans votre .bashrc ou .profile ne sont pas disponibles. Utilisez toujours des chemins absolus pour les commandes et les binaires, ou définissez explicitement PATH en haut du crontab.
La variable MAILTO contrôle le routage de la sortie. Définissez MAILTO="" pour ignorer la sortie, ou MAILTO="admin@example.com" pour la router vers une adresse spécifique. Sans un MTA configuré, la sortie non gérée provoque des échecs silencieux.
Les permissions sur les scripts sont importantes. Un script qui s’exécute correctement de manière interactive peut échouer sous cron s’il n’est pas exécutable (chmod +x) ou s’il référence des fichiers que l’utilisateur cron ne peut pas lire.
Exécution simultanée de jobs. Si un job prend plus de temps que son intervalle, plusieurs instances s’exécuteront simultanément. Utilisez un fichier de verrouillage ou flock pour éviter cela :
0 * * * * /usr/bin/flock -n /tmp/myjob.lock /home/user/long-running-job.sh
Sensibilité au fuseau horaire. Cron utilise le fuseau horaire système par défaut. Sur les serveurs avec UTC défini comme horloge système — ce qui est une pratique standard sur les VPS Hosting et les Serveurs Dédiés — assurez-vous que vos heures planifiées tiennent compte du décalage. Certaines implémentations cron prennent en charge une variable CRON_TZ par crontab.
Validation de la syntaxe Crontab. Avant de déployer une nouvelle entrée crontab en production, validez l’expression à l’aide d’un outil comme crontab.guru pour confirmer que le calendrier correspond à votre intention.
Journalisation et débogage des jobs Cron
Par défaut, cron enregistre l’exécution des jobs dans syslog. Pour afficher l’activité cron récente :
grep CRON /var/log/syslog | tail -50
Sur les systèmes basés sur systemd :
journalctl -u cron --since "1 hour ago"
Si un job ne s’exécute pas, vérifiez :

Le démon cron est actif : systemctl status cron (ou crond sur les systèmes basés sur RHEL)
Le script est exécutable et le chemin est correct
Les champs de temps sont syntaxiquement valides
La sortie n’est pas silencieusement ignorée — ajoutez temporairement >> /tmp/job.log 2>&1

Lors de la gestion de piles d’automatisation complexes sur un VPS avec cPanel, cPanel fournit une interface graphique Cron Jobs dans la section Avancé, qui écrit directement dans le crontab de l’utilisateur. Les jobs ajoutés via cPanel sont entièrement visibles avec crontab -l et se comportent de manière identique aux entrées ajoutées manuellement.

Matrice de décision : quelle couche Cron utiliser

Liste de contrôle des points clés pratiques

• Exécutez crontab -l pour auditer vos propres jobs ; utilisez le modèle de boucle for pour auditer chaque utilisateur sur un serveur multi-locataires.
• Vérifiez toujours /etc/crontab, /etc/cron.d/ et systemctl list-timers --all — crontab -l seul donne une image incomplète.
• Utilisez des chemins absolus pour toutes les commandes et tous les binaires dans les entrées crontab.
• Définissez MAILTO="" ou redirigez explicitement la sortie pour éviter les échecs silencieux sur les serveurs sans MTA.
• Sauvegardez votre crontab avec crontab -l > backup.txt avant toute session de modification.
• Utilisez flock pour éviter l’exécution simultanée de jobs de longue durée.
• Sur les systèmes systemd, vérifiez journalctl -u cron plutôt que de vous fier uniquement à /var/log/syslog.
• Validez les nouvelles expressions temporelles avec un testeur d’expressions cron en ligne avant de les déployer en production.
• Tenez compte de UTC vs. fuseau horaire local sur les instances cloud et VPS Hosting.
• Pour les serveurs Email Hosting ou toute infrastructure où les jobs sont critiques, mettez en place une surveillance externe (par exemple, des pings healthcheck) pour détecter les échecs silencieux de cron.

FAQ

Comment lister tous les jobs cron pour chaque utilisateur sur un serveur Linux ?

Itérez sur /etc/passwd et appelez sudo crontab -l -u <user> pour chaque compte, en supprimant les erreurs « no crontab » avec 2>/dev/null. Inspectez également /etc/crontab, /etc/cron.d/, et exécutez systemctl list-timers --all pour capturer les jobs au niveau système et gérés par systemd.

Pourquoi crontab -l ne montre rien alors que des jobs s’exécutent ?

Les jobs sont probablement définis dans /etc/crontab, un fichier dans /etc/cron.d/, ou comme timers systemd — aucun d’entre eux n’est visible via crontab -l. Cette commande n’affiche que le crontab personnel de l’utilisateur appelant, stocké dans le répertoire spool.

Quelle est la différence entre /etc/crontab et /etc/cron.d/ ?

Les deux utilisent la même syntaxe à six champs (incluant le champ nom d’utilisateur) et sont lus par le démon cron système. /etc/crontab est un fichier monolithique unique destiné à l’administration système manuelle. /etc/cron.d/ est un répertoire drop-in où les paquets ou services individuels installent leurs propres fichiers de jobs, les gardant isolés et plus faciles à gérer ou supprimer indépendamment.

Comment empêcher un job cron d’exécuter plusieurs instances simultanées ?

Encapsulez la commande avec flock -n /tmp/lockfile.lock pour acquérir un verrou exclusif non bloquant. Si une instance précédente est toujours en cours d’exécution, la nouvelle invocation se termine immédiatement sans exécuter la commande, évitant ainsi la contention des ressources et la corruption des données.

Où sont stockés les logs des jobs cron, et comment déboguer un job qui ne s’exécute pas ?

Sur la plupart des systèmes, cron enregistre dans /var/log/syslog (filtrez avec grep CRON) ou via journald (journalctl -u cron). Pour le débogage, ajoutez temporairement >> /tmp/debug.log 2>&1 à la commande du job pour capturer toute la sortie, vérifiez que le script est exécutable, confirmez que le démon est en cours d’exécution avec systemctl status cron, et validez l’expression temporelle indépendamment.