wykonanie skryptu sh z crona

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

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ć.
...

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

1. Cron zapewnia ograniczone środowisko, np. Minimalne $PATHi brak innych oczekiwanych zmiennych.
2. Cron domyślnie wywołuje / bin / sh, podczas gdy możesz używać innej powłoki interaktywnie.
3. Cron traktuje znak% specjalnie (w poleceniu jest on zamieniany na nowy wiersz).
4. 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.

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.