wykonanie skryptu sh z crona

12

Mam skrypt test.sh

#!/bin/sh
php /home/v/file.php
sh /root/x/some.sh

kiedy wykonuję plik jako root z wiersza poleceń, działa.

sh /home/v/test.sh

kiedy ustawię go na crontab -e (to root cron), nie działa

 * * * * * sh /home/v/test.sh

Co robię źle? Dzięki

shell cron

— Elzo Valugi
źródło

„nie działa” nie działa. Widzieć? Nie wiesz, co mam na myśli, a my też nie wiemy, co masz na myśli. Mam na myśli (tak) co nie działa? Może dotyczyć wszystkiego. Być może domysł jest prawidłowy, ale to tylko domysł (i całkiem niezły, jak sądzę, ale nadal).

— Jürgen A. Erhard

Tak, jeśli możesz sprecyzować, jakie wyniki widzisz, będziemy w stanie lepiej określić, na czym polega problem. To znaczy, co masz na myśli

— mówiąc

Nie widzę żadnego dziennika w syslog, a skrypty robią wstawki do bazy danych, które się nie zdarzają, i zdarzają się, jeśli uruchamiam skrypt ręcznie.

— Elzo Valugi,

15

Według mężczyzny:

Demon cron uruchamia podpowłokę z katalogu HOME. Jeśli zaplanujesz uruchamianie polecenia, gdy nie jesteś zalogowany, a chcesz, aby polecenia z pliku .profile były uruchamiane, polecenie musi jawnie odczytać plik .profile.

Demon cron dostarcza domyślne środowisko dla każdej powłoki, definiując HOME, LOGNAME, SHELL (= / usr / bin / sh)
i PATH (= / usr / bin).

Tak więc demon cron nie wie, gdzie jest php i powinieneś ręcznie podać pełną ścieżkę php (nie znam twojej prawdziwej ścieżki PHP):

#!/bin/sh
/usr/local/bin/php /home/v/file.php
sh /root/x/some.sh

Innym sposobem jest na przykład źródło / etc / profile (lub .profile / .bashrc)

* * * * * . /home/v/.bashrc ; sh /home/v/test.sh

Jest to przydatne, jeśli .bashrc ustawia potrzebne zmienne środowiskowe (tj. ŚCIEŻKA)

EDYTOWAĆ

Ciekawą lekturą jest „ Newbie: Intro to cron ”, nie lekceważ artykułu z tytułu (jest to lektura dla wszystkich), w rzeczywistości jest dobrze napisana, kompletna i doskonale odpowiada na twoje pytanie:

...
ŚCIEŻKA zawiera katalogi, które będą na ścieżce wyszukiwania crona, np. Jeśli masz program „foo” w katalogu / usr / cog / bin, może warto dodać / usr / cog / bin do ścieżka, ponieważ powstrzyma Cię to od korzystania z pełnej ścieżki do „foo” za każdym razem, gdy chcesz ją wywoływać.
...

— tmow
źródło

Zła $ PATH jest najczęstszą przyczyną skryptów, które działają ręcznie, ale nie z crona.

— Patrick

@Patrick Oczywiście jest to problem, jeśli cron nie wie, gdzie jest php, w przeciwnym razie crontab Elzo działałby bez żadnych problemów, MUSI to być ŚCIEŻKA.

— tmow

Wielkie dzięki za odpowiedź. Bardzo łatwo mi to działało !!! .. Wielkie dzięki @tmow.

— Vignesh Prajapati

5

Istnieją cztery typowe przyczyny poleceń działających po wpisaniu w terminalu, ale nie z crona, w kolejności pospolitości:

Cron zapewnia ograniczone środowisko, np. Minimalne $PATHi brak innych oczekiwanych zmiennych.
Cron domyślnie wywołuje / bin / sh, podczas gdy możesz używać innej powłoki interaktywnie.
Cron traktuje znak% specjalnie (w poleceniu jest on zamieniany na nowy wiersz).
Cron nie zapewnia środowiska terminalowego ani graficznego.

Jeśli Twoje zadanie generuje jakieś dane wyjściowe, w tym komunikaty o błędach, cron wysyła wiadomość e-mail z całym wynikiem. Upewnij się, że czytasz pocztę otrzymaną lokalnie lub przekazujesz ją na adres, który czytasz. Aby przesłać pocztę z konta lokalnego na inny adres, wpisz inny adres w ~/.forward. Jeśli zadanie cron działa jako użytkownik systemu ( root, webmaster...), upewnij się, że poczta użytkownika jest przekierowany do ciebie (i każdy inny admin); przy większości ustawień poczty wstaw wiersze jak root: elzow /etc/aliases.

— Gilles „SO- przestań być zły”
źródło

2

Demon cron zwykle wykonuje polecenie w powłoce, w której zmienna środowiskowa PATH jest ograniczona do niektórych ustawień domyślnych systemu, np. / Usr / bin: / bin.

Prawdopodobnie twoje phppolecenie nie jest dostępne w / usr / bin lub / bin, a zatem skrypt kończy się niepowodzeniem, gdy jest wykonywany przez cron i działa poprawnie, gdy nie jest.

Cron zwykle zgłasza błędy lub komunikaty zadania pocztą do użytkownika root (tj. Gdy polecenie zwraca status wyjścia! = 0 lub generuje dane wyjściowe do stdout / stderr) po zakończeniu zadania.

W zależności od systemu musisz skonfigurować dostarczanie poczty lokalnej, aby otrzymywać te wiadomości.

— maxschlepzig
źródło