Définition de la commande
Il existe tout d’abord plusieurs endroits dans lequel les tâches planifiées via cron peuvent être configurées, il vous faut donc correctement identifier celui vers lequel vous devez vous tourner. Le critère principal repose sur la portée de votre tâche : système ou utilisateur.
Crontabs système
Les crontabs systèmes sont stockées dans des fichiers respectant la syntaxe suivante :
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7)
# | | | | |
# * * * * * user-name command to be executedNotez la présence du nom de l’utilisateur dans ce format, c’est sous cet identifiant que la tâche sera lancée. Soyez donc particulièrement attentifs lors de la configuration de vos crontabs système, car celles-ci peuvent s’exécuter avec les privilèges maximums si « root » est choisi ce qui peut représenter un risque de sécurité.
Les crontabs systèmes se trouvent sous /etc :
- /etc/crontab est la crontab système principale
- /etc/cron.d est son équivalent mais sous forme de fichiers individuels permettant de regrouper des tâches selon des critères communs. Par exemple un mainteneur de paquet peut installer un fichier regroupant tous les tâches nécessaires au bon fonctionnement du logiciel concerné.
- /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly contiennent des scripts qui seront exécutés toutes les heures, jours, semaines ou mois en tant qu’utilisateur « root ».
Crontabs utilisateur
Les crontabs utilisateur sont stockées dans /var/spool/cron mais ne doivent pas être modifiées directement par un éditeur type vi ou nano, il existe pour cela la commande « crontab ».
Deux switchs sont intéressants dans ce cas :
-
crontab -lpermet d’afficher la crontab de l’utilisateur courant. -
crontab -epermet de la modifier
Dans ce cas, le format utilisé est légèrement différent :
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7)
# | | | | |
# * * * * * command to be executed Vous pouvez noter qu’il s’agit du même format que celui utilisé pour les crontabs système sans la notion d’utilisateur : c’est logique car cette information est dans ce cas-là déjà connue.
Notez que l’utilisateur « root » possède aussi une crontab « utilisateur », il peut donc être utile de la consulter si vous recherchez où est définie une tâche qui s’exécute en tant que root.
Dépannage des commandes
Une fois votre commande localisée, vous pouvez tout d’abord vérifier que sa planification est correctement configurée. Vous pouvez par exemple copier/coller les 5 premières valeurs de votre crontab dans le site suivant qui les décodera dans une version plus compréhensible : https://crontab.guru/
Si la planification vous semble correcte, c’est peut-être bête, mais vous pouvez vérifier que le daemon crond est bien lancé :
$ systemctl status crond
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-05-17 06:17:57 CEST; 1 weeks 1 days ago
Main PID: 229194 (crond)
Tasks: 1 (limit: 10605)
Memory: 1.9M
CGroup: /system.slice/crond.service
└─229194 /usr/sbin/crond -n
On peut faire cette vérification en tant que simple utilisateur. En revanche, si vous constatez que le daemon est arrêté, il sera nécessaire d’avoir des droits d’administration pour le redémarrer.
Une tâche planifiée ajoute normalement une ligne de log dans le syslog, si vous avez des privilèges suffisants vous pouvez donc vérifier sa présence :
# grep -i toto /var/log/cron.log
May 25 11:50:02 server CROND[320085]: (user) CMD (echo toto > /tmp/test-crontab)
Si aucune ligne n’apparaît au moment où la tâche est censée se déclencher, celle-ci n’est vraisemblablement pas correctement traitée par le daemon. Causes possibles : problème de syntaxe (nom d’utilisateur dans une crontab utilisateur ?), erreur de planification, problème global au niveau du daemon, … Normalement les étapes précédentes ont vérifié cela, mais une deuxième passe est peut-être utile.
Vous pouvez aussi à ce stade contrôler l’heure du système pour vérifier qu’elle est correcte :
$ date
jeu. mai 25 12:00:42 CEST 2023
Par défaut, cron capture les sorties des commandes et les envoie par mail à l’utilisateur correspondant. Vous pouvez donc chercher dans la boîte locale s’il n’y a pas quelque chose à ce sujet (la commande « mail » doit être disponible sur la machine).
Vous pouvez aussi capturer les sorties standard et d’erreur vous-mêmes et les rediriger dans un fichier :
* * * * * /votre/commande &> /tmp/ma-commande.log
* * * * * /votre/commande > /tmp/ma-commande.log 2>&1
Les deux syntaxes produisent le même résultat. Une fois l’exécution terminée vous pouvez consulter le contenu du fichier /tmp/ma-commande.log et voir s’il contient des informations intéressantes.
Particularités des commandes lancées via cron
Si vous arrivez à lancer la commande dans un shell interactif, le problème vient peut-être de l’environnement dans lequel les tâches planifiées s’exécutent. En effet, celui-ci ne correspond pas à celui dont vous disposez lorsque vous entrez des commandes vous-mêmes. Vous pouvez par exemple voir la différence sur la variable PATH :
$ echo $PATH
/home/user/.local/bin:/home/user/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
$ crontab -l
* * * * * echo $PATH > /tmp/path.txt
$ cat /tmp/path.txt
/usr/bin:/bin
Si vous avez des erreurs lors de l’exécution, vous pouvez donc vérifier si des variables d’environnement ne sont pas manquantes.
Répertoire courant
Le répertoire courant lors de l’exécution d’un programme via cron est le répertoire home de l’utilisateur correspondant (/home/user pour un utilisateur ou /root pour root par exemple). N’hésitez donc pas à changer explicitement de répertoire au début de votre script ou bien à utiliser des chemins absolus pour lever toute ambigüité.
La dernière commande d’un fichier crontab ne s’exécute pas
Vérifiez si par hasard un dernier retour à la ligne ne serait pas absent à la fin du fichier. En effet, cron s’attend en général à ce que chaque commande soit terminée par un caractère de retour à la ligne (\n).
Références
- https://serverfault.com/questions/449651/why-is-my-crontab-not-working-and-how-can-i-troubleshoot-it
- manpages cron et crontab
Laisser un commentaire