Otázka:
Výchozí prostředí pro vydání cronu
cupakob
2012-10-10 13:02:53 UTC
view on stackexchange narkive permalink

Mám nějaké příkazy, fungují pod bash, ale ne jako cronjob. Chcete-li zjistit, co způsobuje problém, ukládám výstup do souboru, zde je můj příklad: 

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

Obsah souboru protokolu je: 

  / bin / sh: 1: zdroj: nenalezen

To znamená, že cron používá sh místo bash . Snažil jsem se to změnit v /etc/crontab:

SHELL=/bin/bash

Ale toto nefunguje. Podíval jsem se do / etc / passwd a tady vidím, že démon používá sh jako výchozí shell. root a pi mají jako výchozí shell bash . 

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

Co mám udělat, abych změnil výchozí shell pro cron? Nenastavil bych / bin / bash pro uživatele démona v / etc / passwd ... imho to není dobrý nápad.

ed

  ls -l / bin / shlrwxrwxrwx 1 root root 4. března 2012 / bin / sh -> dash

zde obsah /etc/crontab:

  # / etc / crontab: celosystémový crontab # Na rozdíl od jiných crontab nemusíte spouštět příkaz `crontab '# k instalaci nové verze při úpravách tohoto souboru # a souborů v /etc/cron.d. Tyto soubory mají také pole uživatelského jména, # která žádná z ostatních crontabů nedělá. 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 kořenový test -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.weekly) 52 6 1 * * root test -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.monthly) #

Proč chcete `zdrojovat 'v prostředí crons? Pouhé spuštění souboru `~ / .rvm / scripts / rvm` nefunguje? A _ _ můžete mít problémy s používáním ~ v non-bash prostředí.
čtyři odpovědi:
Krzysztof Adamski
2012-10-10 13:07:33 UTC
view on stackexchange narkive permalink

Většina takových případů (kde skript funguje ve skořápce, ale ne v cronu) je způsoben proměnnými prostředí, které se ve skriptu liší. V mnoha případech jsou problémy proměnnou PATH . Můžete použít úplné cesty ke všem spustitelným souborům, které ve skriptu používáte, nebo upravit PATH v prvním řádku skriptu.

Chcete-li tyto problémy sledovat, můžete začít s vypouštěním proměnných prostředí aviable do skriptu pomocí příkazu env , například: / usr / bin / env> /tmp/env.txt

nemám ve svém skriptu žádné proměnné prostředí ... a / bin / env neexistuje.
Ne, vždy máte v každém shellu nějaké proměnné prostředí. Jedním z příkladů je `PATH`, který již byl zmíněn. Místo toho zkuste `/ usr / bin / env`. Nebo použijte `which env` ke kontrole, jaká je vaše úplná cesta k` env` util.
Alex Chamberlain
2012-10-10 13:12:14 UTC
view on stackexchange narkive permalink

Použitý shell je dash ; prostředí kompatibilní s POSIX, které je navrženo tak, aby bylo mnohem menší a stabilnější než bash.

Dalo by se namítnout, že byste měli psát cron úlohy být kompatibilní s POSIX. Případně zkuste zapouzdřit svou logiku do skriptu a připravit shebang 

  #! / Usr / bin / env bash
proč #! / usr / bin / env bash a ne #! / bin / bash? jaký je rozdíl?
IMHO není moc. Přísně vzato umožňuje uložení `bash` na jiné místo. Kdo by to udělal, nevím!
Zkoušel jsem to také ... mám obálkový bash skript, který volá můj příkaz, ale také to nefunguje. Ale bloudím, proč změny v souboru / etc / crontab nedělají z toho bash.
@cupakob Můžete prosím vložit celý soubor `/ etc / crontab`?
najdete to v mém příspěvku
Myslím, že problém je `source` je vestavěný, který nemá smysl běžet sám o sobě.
pojďme [pokračovat v této diskusi v chatu] (http://chat.stackexchange.com/rooms/6073/discussion-b Between-cupakob-and-alex-chamberlain)
Avio
2012-10-10 15:48:16 UTC
view on stackexchange narkive permalink

Jste si jisti, že získávání vašeho skriptu do cron je naprosto to, co chcete dělat, a co je důležitější, nutné? Myslím, že je to téměř vždy špatný nápad.

Kromě toho, když upravujete cron (stejně jako další nástroje, které mohou případně spustit jiní uživatelé nebo jiné skořápky), zkuste postupovat krok za krokem -krokový přístup. Můžete například otestovat své prostředí něčím podobným: 

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

nebo dokonce: 

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

Takže můžete mít důkaz o svém prostředí atd.

Abych odpověděl na vaši otázku, nezměnil bych prostředí pro cron . Jednoduše bych řekl, aby zavolal bash a pak nechal bash volat vaše skripty.

$ SHELL byl stále 'sh' bez ohledu na to, že jsem to změnil v / etc / crontab
Ano, je to také výchozí nastavení v mém `cron`. Jak jsem řekl, nezměnil bych to. Stačí zavolat skript pomocí `bash` pomocí` bash -c "yourscript" "a vše by mělo být v pořádku (zdrojový skript nepoužívejte, pravděpodobně ho nepotřebujete!)
ano, bude to fungovat, ale chci vědět, proč nebyl změněn výchozí shell.
cupakob
2012-10-11 02:27:09 UTC
view on stackexchange narkive permalink

Takže .... mám pro svůj problém dvě řešení:

  1. Obálka skriptu přes příkaz bash, který v tuto chvíli volám jako cronjob. Problém zde - pro každou cronjob potřebuji jeden obal, a to pro mě není nejlepší řešení.

  2. Snažil jsem se zavolat rubínový skript jako cronjob. To nefunguje, tak jsem si myslel, že musím zavolat 'rvm use 1.9.3' a proto musím nejdříve zavolat 'source ~ / .rvm / scripts / rvm'. A tady byla moje chyba. V mém případě bash mám cestu k rubínu, ale ne jako cron. Poté, co jsem to napravil, vše funguje dobře a mohu spouštět své rubínové skripty jako cronjob.

Alex Chamberlain mi hodně pomohl a dal mi nejdůležitější nápovědu . Mnohokrát děkujeme za pomoc !!!



ⓘ
Tyto otázky a odpovědi byly automaticky přeloženy z anglického jazyka.Původní obsah je k dispozici na webu stackexchange, za který děkujeme za licenci cc by-sa 3.0, pod kterou je distribuován.
Loading...