Pourquoi les crontab scripts ne fonctionnent pas ?

Question

Pourquoi les crontab scripts ne fonctionnent pas ?

Demandé el 24 de Janvier, 2011: Quand la question a-t-elle été
1229768 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

Souvent, crontab Les scripts ne sont pas exécutés dans les délais ou comme prévu. Il y a de nombreuses raisons à cela :

mauvaise notation de la crontab
problème de permissions
variables d'environnement

Ce wiki communautaire a pour objectif de rassembler les principales raisons pour lesquelles crontab Les scripts ne sont pas exécutés comme prévu. Écrivez chaque raison dans une réponse séparée.

Veuillez inclure une raison par réponse - des détails sur la raison pour laquelle elle n'est pas exécutée - et la ou les corrections pour cette raison.

Veuillez écrire uniquement les problèmes spécifiques à cron, par exemple les commandes qui s'exécutent comme prévu depuis le Shell mais qui s'exécutent de manière erronée par cron.

Demandé el 24 de Janvier, 2011 par DanV

16 votes

Vous devez fermer crontab -e pour que le cron prenne effet. Par exemple, en utilisant vim, j'édite le fichier et utilise :w pour l'écrire mais le travail n'est pas ajouté à cron jusqu'à ce que je quitte aussi. Je ne verrai donc pas la tâche avant d'avoir :q également.

Commenté el 24 de Juin, 2014 par DutGRIFF

0 votes

Je pense que la meilleure façon de déboguer cron est de vérifier syslog et de trouver les problèmes.

Commenté el 23 de Juin, 2016 par Suneel Kumar

0 votes

Dans mon cas, l'e-mail a été envoyé dans mon dossier SPAM, alors..... vérifier cela avant de passer des heures à déboguer :D

Commenté el 6 de Novembre, 2017 par KPBird

Afficher 2 autres commentaires

Answer 1

5 Réponses

Answer 2

595voto

Steve Karg Points 11

Un environnement différent

Cron transmet un ensemble minimal de variables d'environnement à vos travaux. Pour voir la différence, ajoutez un travail fictif comme ceci :

\* \* \* \* \* env > /tmp/env.output

Attendez /tmp/env.output à créer, puis supprimez à nouveau le travail. Comparez maintenant le contenu de /tmp/env.output avec la sortie de env exécuté dans votre terminal habituel.

Un "gotcha" commun ici est le PATH La variable d'environnement est différente. Peut-être que votre cron script utilise la commande somecommand trouvé dans /opt/someApp/bin que vous avez ajouté à PATH en /etc/environment ? le cron ignore PATH de ce fichier, donc l'exécution somecommand de votre script échouera lorsqu'il sera exécuté avec cron, mais fonctionnera lorsqu'il sera exécuté dans un terminal. Il est intéressant de noter que les variables de /etc/environment seront transmises aux tâches cron, mais pas les variables que cron définit lui-même, telles que PATH .

Pour contourner ce problème, il suffit de définir votre propre PATH au début du script. Ex.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Certains préfèrent utiliser les chemins absolus pour toutes les commandes. Je ne le recommande pas. Considérez ce qui se passe si vous voulez exécuter votre script sur un système différent, et que sur ce système, la commande est en /opt/someAppv2.2/bin à la place. Il faudrait passer par l'ensemble du script en remplaçant /opt/someApp/bin avec /opt/someAppv2.2/bin au lieu de simplement faire une petite modification sur la première ligne du script.

Vous pouvez également définir la variable PATH dans le fichier crontab, qui s'appliquera à toutes les tâches cron. Par exemple

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

Répondu el 26 de Janvier, 2011 par Steve Karg (11 Points )

6 votes

Je crois que je viens de tomber dans le panneau, et le saut de ligne à la fin... double malchance.

Commenté el 2 de Juin, 2011 par WernerCD

0 votes

+1 C'est la raison principale pour laquelle j'ai eu un mal de tête avec un script cronné qui utilisait grep et ls, le chemin était vide sous l'env de cron, heh.

Commenté el 25 de Juin, 2011 par DM8

9 votes

+1 pour env J'avais complètement oublié cette commande et je pensais que PATH fonctionnait. En fait, c'était légèrement différent dans mon cas.

Commenté el 18 de Janvier, 2012 par Matthieu Napoli

Afficher 20 autres commentaires

Answer 3

405voto

user4124 Points 8203

Ma principale erreur : si vous oubliez d'ajouter un saut de ligne à la fin de l'instruction crontab fichier. En d'autres termes, le fichier crontab doit se terminer par une ligne vide.

Vous trouverez ci-dessous la section pertinente des pages de manuel concernant cette question ( man crontab puis passez à la fin) :

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Répondu el 26 de Janvier, 2011 par user4124 (8203 Points )

119 votes

C'est un tel casse-tête, comment se fait-il qu'il n'ait pas été corrigé depuis tant d'années de cron ?

Commenté el 27 de Janvier, 2011 par Eugene Yokota

2 votes

Cela semble être corrigé dans le cron de Vixie : man crontab sur Ubuntu 10.10 dit "cron exige que chaque entrée dans une crontab se termine par un caractère de nouvelle ligne. Si la dernière entrée d'une crontab ne comporte pas de nouvelle ligne, cron considérera que la crontab est (au moins partiellement) cassée et refusera de l'installer." (Et la date indiquée à la fin est le 19 avril 2010).

Commenté el 1 de Février, 2011 par Michiel de Mare

21 votes

@barraponto C'est en fait un bug dans les nouveaux éditeurs de texte. Le caractère "nouvelle ligne" est supposé être un terminaison de ligne Ainsi, la dernière ligne d'un fichier texte est censée se terminer par un caractère de nouvelle ligne qui n'est pas affiché dans l'éditeur. Vi et vim utilisent le caractère correctement, et cron a été construit avant que les nouveaux éditeurs n'aient leur comportement étrange... D'où le fait d'enregistrer et d'inclure une ligne blanche.

Commenté el 18 de Janvier, 2012 par Matthieu Napoli

Afficher 10 autres commentaires

Answer 4

174voto

Thomas Points 715

Le démon Cron ne fonctionne pas. J'ai vraiment merdé avec ça il y a quelques mois.

Type :

pgrep cron

Si vous ne voyez pas de numéro (c'est-à-dire le PID principal de cron), alors cron ne fonctionne pas. sudo /etc/init.d/cron start peut être utilisé pour démarrer cron.

EDIT : Plutôt que d'invoquer init scripts à travers /etc/init.d, utilisez l'utilitaire service par exemple

sudo service cron start

EDIT : Vous pouvez aussi utiliser systemctl dans les Linux modernes, par ex.

sudo systemctl start cron

Répondu el 27 de Janvier, 2011 par Thomas (715 Points )

58 votes

Merci de m'avoir montré pgrep. J'ai continué à faire ps -ef | grep foo

Commenté el 17 de Mars, 2011 par Ahsan

4 votes

Vous pouvez également utiliser pidof cron qui omettra les résultats pour les autres applications qui ont également le mot 'cron', comme crontab.

Commenté el 11 de Mars, 2014 par dmd

0 votes

Bizarre, tout cela ne me donne rien qui montre que cron est en cours d'exécution, mais si j'exécute sudo service cron start Je reçois start: Job is already running: cron

Commenté el 6 de Avril, 2015 par Colleen

Afficher 1 autres commentaires

Answer 5

83voto

RelaXNow Points 1164

Dans de nombreux environnements, cron exécute des commandes en utilisant sh alors que beaucoup de gens pensent qu'il utilisera bash .

Suggestions de test ou de correction pour une commande qui échoue :

Essayez d'exécuter la commande dans sh pour voir si ça marche :
```
sh -c "mycommand"
```
Enveloppez la commande dans un sous-shell bash pour être sûr qu'elle sera exécutée dans bash :
```
bash -c "mybashcommand"
```
Dites à cron d'exécuter toutes les commandes en bash en définissant le Shell en haut de votre crontab :
```
SHELL=/bin/bash
```
Si la commande est un script, assurez-vous que le contient un shebang :
```
#!/bin/bash
```

Répondu el 25 de Juin, 2011 par RelaXNow (1164 Points )

1 votes

La suggestion de bash est très utile, elle a permis de résoudre un problème avec mon cron.

Commenté el 18 de Février, 2016 par Maxim Galushka

1 votes

Cela vient de me coûter 1 heure de bricolage et de dépannage. Encore plus perplexe si vous n'êtes pas au courant du problème, le script s'exécute manuellement sans problème si votre typique est bash mais pas avec cron . Merci !

Commenté el 22 de Novembre, 2016 par Hendy

1 votes

Il y a longtemps, j'ai rencontré quelque chose de similaire : La commande source est dans bash mais pas dans sh. Dans cron/sh, utilisez un point : . envfile plutôt que source envfile .

Commenté el 22 de Décembre, 2017 par kungphu

Afficher 2 autres commentaires

Answer 6

52voto

luissquall Points 101

J'ai eu des problèmes avec les fuseaux horaires. Cron fonctionnait avec le fuseau horaire de la nouvelle installation. La solution a été de redémarrer cron :

sudo service cron restart

Répondu el 7 de Février, 2012 par luissquall (101 Points )

8 votes

Oui, après avoir changé le fuseau horaire d'un système, il faut soit redémarrer tous les services qui se soucient de l'heure, soit redémarrer. Je préfère le redémarrage, pour être sûr d'avoir tout pris en compte.

Commenté el 9 de Avril, 2012 par lacker

0 votes

Oh pour l'amour de Dieu, tu as tué des heures sur ça. J'ai essayé de redémarrer le service après * * * * * touch /tmp/cronworks n'a rien fait, pourtant il y a RELOAD à cronlog.

Commenté el 1 de Octobre, 2014 par НЛО

0 votes

Cela a résolu le problème, même s'il n'y avait aucun problème avec mon fuseau horaire.

Commenté el 16 de Mai, 2020 par Aven Desta

Afficher 1 autres commentaires

Pourquoi les crontab scripts ne fonctionnent pas ?

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

Pourquoi les crontab scripts ne fonctionnent pas ?

Réponses

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: