Question:
Shell par défaut pour le problème de cron
cupakob
2012-10-10 13:02:53 UTC
view on stackexchange narkive permalink

J'ai quelques commandes, elles fonctionnent sous bash, mais pas comme cronjob. Pour voir, quelle est la cause du problème, j'enregistre la sortie dans un fichier, voici mon exemple:

  51 * * * * source ~ / .rvm / scripts / rvm >> stack.log 2>&1  

Le contenu du fichier journal est:

  / bin / sh: 1: source: introuvable  

Cela signifie que cron utilise sh à la place de bash . J'ai essayé de le changer dans le /etc/crontab:

SHELL=/bin/bash

Mais ceci ne fonctionne pas. J'ai regardé dans le / etc / passwd et ici je vois, que le démon utilise sh comme shell par défaut. root et pi ont bash comme shell par défaut.

  root: x: 0: 0: root : / root: / bin / bashdaemon: x: 1: 1: démon: / usr / sbin: / bin / shpi: x: 1000: 1000: ,,,: / home / pi: / bin / bash  

Que dois-je faire pour changer le shell par défaut pour cron? Je ne définirais pas / bin / bash pour l'utilisateur du démon dans / etc / passwd ... à mon avis, ce n'est pas une bonne idée.

edit

  ls -l / bin / shlrwxrwxrwx 1 racine racine 4 30 mars 2012 / bin / sh -> dash  

voici le contenu du /etc/crontab:

  # / etc / crontab: crontab à l'échelle du système # Contrairement à tout autre crontab que vous n'avez pas à exécuter la commande `crontab '# pour installer la nouvelle version lorsque vous éditez ce fichier # et les fichiers dans /etc/cron.d. Ces fichiers ont également des champs de nom d'utilisateur, # qu'aucun des autres crontabs ne fait.SHELL = / bin / bashPATH = / usr / local / sbin: / usr / local / bin: / sbin: / bin: / usr / sbin: / usr / bin # mh dom mon dow user command17 * * * * root cd / && run-parts --report /etc/cron.hourly25 6 * * * root test -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.daily)
47 6 * * 7 test de racine -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.weekly) 52 6 1 * * test racine -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.monthly) #  
Pourquoi voulez-vous "source" dans l'environnement crons? Lancer simplement `~ / .rvm / scripts / rvm` ne fonctionne pas? Et vous _pouvez_ avoir des problèmes avec l'utilisation de ~ dans des environnements non-bash.
Quatre réponses:
#1
+4
Krzysztof Adamski
2012-10-10 13:07:33 UTC
view on stackexchange narkive permalink

La plupart de ces cas (où le script fonctionne dans shell mais pas dans cron) sont dus à des variables d'environnement qui sont différentes dans le script. Dans de nombreux cas, le problème est la variable PATH . Vous pouvez utiliser des chemins complets vers tous les exécutables que vous exécutez dans le script ou modifier PATH dans la première ligne de votre script.

Pour tracer de tels problèmes, vous pouvez commencer par vider les variables d'environnement disponibles à votre script en utilisant la commande env , comme ceci: / usr / bin / env> /tmp/env.txt

je n'ai aucune variable d'environnement dans mon script ... et / bin / env n'existe pas.
Non, vous avez toujours des variables d'environnement dans chaque shell. Un exemple est «PATH» qui a déjà été mentionné. Essayez plutôt `/ usr / bin / env`. Ou utilisez `which env` pour vérifier quel est votre chemin complet vers` env` util.
#2
+4
Alex Chamberlain
2012-10-10 13:12:14 UTC
view on stackexchange narkive permalink

Le shell utilisé est dash ; un shell compatible POSIX, qui est conçu pour être beaucoup plus petit et plus stable que bash.

On pourrait dire que vous devriez écrire des travaux cron pour être conforme à POSIX. Vous pouvez également essayer d'encapsuler votre logique dans un script et d'ajouter le shebang au début

  #! / Usr / bin / env bash  
pourquoi #! / usr / bin / env bash et non #! / bin / bash? Quelle est la différence?
IMHO pas beaucoup. Strictement parlant, cela permet à «bash» d'être stocké ailleurs. Qui ferait ça, je ne sais pas!
J'ai essayé cela aussi ... j'ai un script bash wrapper, qui appelle ma commande, mais cela ne fonctionne pas non plus. Mais je me promène, pourquoi les changements dans / etc / crontab ne font pas basculer vers bash.
@cupakob Pouvez-vous coller tout votre `/ etc / crontab` s'il vous plaît?
tu peux le trouver dans mon post
Je pense que le problème est que «source» est une fonction intégrée, ce qui n'a pas de sens de fonctionner en soi.
laissez-nous [continuer cette discussion dans le chat] (http://chat.stackexchange.com/rooms/6073/discussion-between-cupakob-and-alex-chamberlain)
#3
+3
Avio
2012-10-10 15:48:16 UTC
view on stackexchange narkive permalink

Êtes-vous sûr que sourcer votre script dans cron est absolument ce que vous voulez faire et, plus important encore, nécessaire? Je pense que c'est presque toujours une mauvaise idée.

De plus, lorsque vous éditez cron (ainsi que d'autres outils qui peuvent être éventuellement lancés par d'autres utilisateurs et / ou d'autres shells), essayez de faire un pas en avant -approche par étapes. Par exemple, vous pouvez tester votre environnement avec quelque chose comme ceci:

  42 * * * * bash -c "echo home --- $ HOME ---" >> / tmp / cron-temp .log 2>&142 * * * * bash -c "echo shell --- $ SHELL ---" >> /tmp/cron-temp.log 2>&1  

ou même:

  42 * * * * bash -c "export" >> /tmp/cron-temp.log 2>&1  

Vous pouvez donc avoir une preuve de votre environnement, etc.

Pour répondre à votre question, je ne changerais pas le shell pour cron . Je lui dirais simplement d'appeler bash , puis de laisser bash appeler vos scripts.

le $ SHELL était toujours 'sh' même si je l'ai changé dans / etc / crontab
Oui, c'est aussi la valeur par défaut dans mon `cron`. Comme je l'ai dit, je ne changerais rien. Appelez simplement votre script via `bash` avec` bash -c "yourscript" `et tout devrait bien se passer (ne sourcez pas votre script, vous n'en avez probablement pas besoin!)
oui, cela fonctionnera, mais je veux savoir pourquoi le shell par défaut n'a pas été modifié.
#4
+3
cupakob
2012-10-11 02:27:09 UTC
view on stackexchange narkive permalink

Donc .... j'ai deux solutions pour mon problème:

  1. Script wrapper sur la commande bash, que j'appelle pour le moment cronjob. Le problème ici - pour chaque cronjob, j'ai besoin d'un wrapper, et ce n'est pas la meilleure solution pour moi.

  2. J'ai essayé d'appeler un script ruby ​​comme cronjob. Cela ne fonctionne pas, alors j'ai pensé, je dois appeler «rvm use 1.9.3» et pour cela, je dois d'abord appeler «source ~ / .rvm / scripts / rvm». Et voici mon erreur. Dans mon exemple bash, j'ai le chemin vers ruby, mais pas en tant que cron. Après avoir résolu ce problème, tout fonctionne correctement et je peux exécuter mes scripts ruby ​​en tant que cronjob.

Alex Chamberlain m'a beaucoup aidé et m'a donné les conseils les plus importants . Merci beaucoup pour l'aide !!!



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...