crontab sous Linux : syntaxe, règles PATH et suivi des logs

La commande crontab planifie des tâches récurrentes en arrière-plan sur les systèmes Linux via le démon cron. Automatiser des tâches de manière fiable nécessite de modifier les tables utilisateur avec crontab -e, de définir cinq champs temporels et de fournir des chemins absolus vers les binaires pour éviter les échecs d'exécution causés par un environnement shell par défaut restreint sous cron.

La syntaxe temporelle à cinq champs dans crontab -e

La table cron analyse les directives à l'aide de cinq paramètres temporels suivis de la commande exécutée par le système d'exploitation. La syntaxe exacte se lit séquentiellement de gauche à droite : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12) et jour de la semaine (0-7, où 0 et 7 indiquent tous deux le dimanche).

Pour modifier les directives cron du compte système actif, lancez l'outil de configuration interactif standard :

crontab -e

Dans ce fichier de configuration, les astérisques désignent des jokers pour chaque unité temporelle, les virgules délimitent les valeurs discrètes, les tirets spécifient des plages inclusives et les barres obliques définissent des intervalles. Lors de la gestion de ces configurations depuis des appareils mobiles, des outils comme le clavier spécialisé de termi1 pour iOS et Android fournissent les touches manquantes telles qu'Esc, Ctrl, les flèches et Tab, simplifiant les modifications dans nano ou Vim.

# Run database backups from Monday through Friday at 03:30
30 3 * * 1-5 /usr/local/bin/backup-cleanup.sh

# Run an external health check request every 15 minutes
*/15 * * * * /usr/bin/curl -fsS https://example.com/healthcheck

Résoudre l'environnement PATH restreint dans crontab

Le démon cron ne charge jamais les fichiers d'environnement interactifs tels que ~/.bashrc, ~/.zshrc ou /etc/profile. Sur les installations Linux standard, la variable PATH par défaut sous cron se limite strictement à /usr/bin:/bin, provoquant des échecs silencieux dès que les scripts font référence à des binaires situés dans /usr/local/bin, des répertoires utilisateur ou des environnements d'exécution applicatifs.

Les administrateurs système utilisent trois méthodes pour résoudre les écarts d'environnement au sein de crontab :

1. Utiliser des chemins absolus pour tous les utilitaires système, en appelant /usr/local/bin/node ou /usr/bin/python3 au lieu des simples noms de commandes.
2. Définir la variable PATH tout en haut du fichier de configuration crontab avant de déclarer les tâches.
3. Spécifier le shell d'exécution explicitement avec SHELL=/bin/bash pour éviter les divergences de dialecte shell avec /bin/sh.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

0 2 * * * backup-database --all

Rediriger stdout et stderr pour capturer les sorties de cron

Le démon cron tente de transmettre toute sortie générée par les processus planifiés à l'utilisateur local via l'agent de transfert de courrier (MTA) local. Si la machine distante ne dispose pas d'un agent de messagerie local fonctionnel tel que Postfix, tous les journaux d'exécution et les sorties d'erreurs critiques sont ignorés silencieusement.

Pour inspecter les résultats des tâches et diagnostiquer les problèmes, vous devez rediriger la sortie standard (descripteur de fichier 1) et l'erreur standard (descripteur de fichier 2) vers un fichier journal cible explicite sur le système de fichiers :

0 4 * * * /usr/local/bin/sync-storage.sh >> /var/log/sync-storage.log 2>&1

L'opérateur de redirection >> ajoute le texte d'exécution sans tronquer les entrées de journal précédentes, tandis que l'expression 2>&1 fusionne stderr dans stdout. Lors du dépannage de serveurs depuis un client mobile, vous pouvez inspecter ou télécharger ces fichiers journaux de destination directement à l'aide d'un navigateur SFTP intégré sans fermer votre session de terminal.

Vérifier l'exécution des tâches avec journalctl -u cron

Systemd enregistre chaque horodatage d'invocation et état d'exécution de cron dans le journal central du système. L'unité de service est nommée cron sur les distributions Debian et Ubuntu, tandis que les systèmes RHEL et Fedora l'enregistrent sous le nom crond.

Pour confirmer si le service de planification a déclenché votre tâche à l'intervalle prévu, interrogez le journal unifié à l'aide de systemd :

# On Debian, Ubuntu, and derivatives
journalctl -u cron -n 50 --no-pager

# On RHEL, Rocky Linux, and Fedora
journalctl -u crond -n 50 --no-pager

Pour suivre les événements d'exécution en direct pendant les phases de test planifiées, exécutez le suivi du journal :

journalctl -u cron -f

Lors de la consultation des journaux en direct sur des connexions cellulaires instables, l'utilisation de Mosh garantit que votre connexion de terminal reste réactive lors des transitions entre Wi-Fi et données mobiles sans interrompre votre session interactive.

Comparaison de la gestion de crontab : terminal mobile versus ordinateur

La gestion de l'automatisation des serveurs sur différents appareils clients introduit des différences opérationnelles notables :

Si les systèmes cibles manquent de points de terminaison publics accessibles ou de ports ouverts, les administrateurs peuvent router le trafic en toute sécurité via des réseaux maillés superposés tels que Prialo pour accéder à l'infrastructure privée en toute sécurité.

Questions fréquentes

Pourquoi une tâche crontab échoue-t-elle alors que la commande exacte fonctionne dans un terminal interactif ?

crontab exécute les commandes dans un environnement minimaliste qui n'hérite pas des variables de profil du shell. Si un script dépend de chemins personnalisés, de variables d'environnement ou de binaires hors des dossiers système par défaut, il échoue sans chemins absolus ou déclaration explicite de PATH en en-tête.

Comment inspecter les tâches cron de l'utilisateur actuel sans ouvrir d'éditeur ?

La commande crontab -l affiche directement le contenu de la table crontab de l'utilisateur actuel sur la sortie standard sans verrouiller ni modifier de fichiers. Pour afficher les tâches planifiées d'un autre compte utilisateur spécifique, exécutez crontab -u username -l avec les privilèges root.

À quoi sert le jeton spécial @reboot dans crontab ?

Le jeton @reboot remplace les cinq champs temporels standards dans une entrée crontab. Cette directive ordonne au service cron de lancer le script ou la commande binaire désignée une seule fois, immédiatement après que le serveur a terminé la séquence de démarrage de son système d'exploitation.

Où se trouvent les journaux de cron si un serveur n'utilise pas systemd ?

Sur les systèmes Linux utilisant des démons syslog classiques sans systemd journald actif, les notifications d'exécution de cron se trouvent dans /var/log/syslog pour les systèmes Debian et Ubuntu, ou dans /var/log/cron pour les distributions appartenant à la famille Red Hat.