La raison la plus fréquente pour laquelle j'ai vu le programme cron échouer était mal programmée. Il faut de la pratique pour spécifier un travail planifié pour 23h15 au 15 23 * * *
lieu de * * 11 15 *
ou 11 15 * * *
. Le jour de la semaine pour les travaux après minuit est également confus. MF est 2-6
après minuit, non 1-5
. Les dates spécifiques sont généralement un problème car nous les utilisons rarement, * * 3 1 *
pas le 3 mars. Si vous n’êtes pas sûr, consultez vos plannings cron en ligne à l’ adresse https://crontab.guru/ .
Si vous travaillez avec différentes plates-formes en utilisant des options non prises en charge, telles que les 2/3
spécifications temporelles, peut également entraîner des défaillances. C'est une option très utile mais non disponible universellement. J'ai également rencontré des problèmes avec des listes comme 1-5
ou 1,3,5
.
L'utilisation de chemins non qualifiés a également causé des problèmes. Le chemin par défaut est généralement /bin:/usr/bin
utilisé afin que seules les commandes standard soient exécutées. Ces répertoires n'ont généralement pas la commande souhaitée. Cela affecte également les scripts utilisant des commandes non standard. D'autres variables d'environnement peuvent également être manquantes.
Clobber entièrement une crontab existante m'a causé des problèmes. Je charge maintenant à partir d'une copie de fichier. Cela peut être récupéré à partir de la crontab existante en utilisant crontab -l
si elle est bouchée. Je garde la copie de crontab dans ~ / bin. Il est commenté tout au long et se termine par la ligne # EOF
. Ceci est rechargé quotidiennement à partir d'une entrée crontab comme:
#! / usr / bin / crontab
# Recharger cette crontab
#
54 12 * * * $ {HOME} / bin / crontab
La commande de rechargement ci-dessus repose sur une crontab exécutable avec un chemin de bang exécutant crontab. Certains systèmes nécessitent la crontab en cours d'exécution dans la commande et la spécification du fichier. Si le répertoire est partagé sur le réseau, j'utilise souvent crontab.$(hostname)
le nom du fichier. Cela corrigera éventuellement les cas où la mauvaise crontab est chargée sur le mauvais serveur.
L'utilisation du fichier fournit une sauvegarde de ce que devrait être la crontab, et permet aux éditions temporaires (la seule fois que j'utilise crontab -e
) d'être annulées automatiquement. Des en-têtes sont disponibles pour vous aider à définir correctement les paramètres de planification. Je les ai ajoutés lorsque des utilisateurs inexpérimentés éditaient une crontab.
Rarement, j'ai rencontré des commandes nécessitant l'intervention de l'utilisateur. Celles-ci échouent sous crontab, bien que certaines fonctionnent avec la redirection d’entrée.
crontab -e
pour que le cron prenne effet. Par exemple, avec vim, je modifie le fichier et l’utilise:w
pour l’écrire, mais le travail n’est pas ajouté à Cron tant que je n’ai pas quitté. Donc, je ne verrai pas le travail avant après:q
aussi.