Co to jest „katalog roboczy”, gdy cron wykonuje zadanie?

Mam skrypt, który działa, gdy uruchamiam go z wiersza poleceń, ale kiedy go cronplanuję, otrzymuję błędy, że nie może znaleźć plików ani poleceń. Moje pytanie jest dwojakie:

1. Czy podczas planowania zadania cron używa crontab -eon mojego ID użytkownika jako podstawy dla jego uprawnień? Czy też używa jakiegoś rodzaju identyfikatora użytkownika cron i powiązanych uprawnień?

2. Po uruchomieniu zadania cron, jaki jest katalog roboczy? Czy to katalog, w którym określam skrypt do uruchomienia, czy inny katalog?

Oto moja praca Crona:

15 7 * * * /home/xxxx/Documents/Scripts/email_ip_script.sh

Oto rzeczywisty skrypt:

vIP_ADDR="`curl automation.whatismyip.com/n09230945.asp`"
echo "$vIP_ADDR"
sed "s/IPADDR/$vIP_ADDR/g" template.txt > emailmsg.txt
ssmtp XXXXX@gmail.com < emailmsg.txt

Oto błędy, które otrzymuję, gdy przeglądam mailkomunikat wyprodukowany przez cron:

sed: can't read template.txt: No such file or directory
/home/xxxx/Documents/Scripts/email_ip_script.sh: line 15: ssmtp: command not found

Nie można go znaleźć, template.txtale znajduje się w tym samym katalogu co skrypt. To także nie może działać ssmtp, ale mogę jako mój użytkownik. Czego mi brakuje, żeby to działało poprawnie?

Dodaj, cd /home/xxxx/Documents/Scripts/jeśli chcesz, aby twoje zadanie działało w tym katalogu. Nie ma powodu, dla którego cron miałby przejść do tego konkretnego katalogu. Cron uruchamia twoje polecenia w twoim katalogu domowym.

Jeśli chodzi o ssmtp, może nie być w domyślnej PATH. Domyślna ścieżka Cron jest zależna od implementacji, więc sprawdź swoją stronę człowieka, ale z całą pewnością ssmtpjest w /usr/sbinktórych nie ma w domyślnej PATH, tylko root.

PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
15 7 * * * cd /home/xxxx/Documents/Scripts && ./email_ip_script.sh

Jeśli twój cronjob jest skryptem bashowym, poniższe CD zapisze lokalizację jego skryptu (zakładając, że używasz ścieżki bezwzględnej w definicji crona):

cd "$(dirname "$0")";

Aby odpowiedzieć na pytanie 1: jeśli uruchomisz crontab -ejako własny użytkownik, zadania będą zaplanowane w crontab tego użytkownika, a zatem będą działać z uprawnieniami tego użytkownika.

Musisz jednak wziąć pod uwagę, że zadania będą działać w nieinteraktywnej powłoce, co oznacza, że ​​$ PATH może różnić się od tej, którą masz podczas uruchamiania skryptu z wiersza poleceń.

Najlepiej zawsze używać pełnych ścieżek w skryptach, zwłaszcza jeśli planujesz je zaplanować za pomocą at / cron itp.

Polecam również stosowanie pełnych ścieżek do wszystkich plików, aby uniknąć dokładnie problemów, które widzisz.

Aby zapobiec warunkom wyścigu i innym problemom bezpieczeństwa, powinieneś również mktempupewnić się, że czytany plik nie jest modyfikowany przez nic poza skryptem.

Więc zmieniłbym skrypt na coś takiego:

vIP_ADDR="`curl automation.whatismyip.com/n09230945.asp`"
echo "$vIP_ADDR"
mail_msg=`/bin/mktemp`
/bin/sed "s/IPADDR/$vIP_ADDR/g" /home/xxxx/Documents/Scripts/template.txt > $mailmsg
/path/to/ssmtp XXXXX@gmail.com < $mailmsg
/bin/rm $mailmsg

cronuruchamia zaplanowane zadania każdego użytkownika jako tego użytkownika. To powinno wystarczyć, abyśmy zorientowali się, że uruchamia twoje skrypty względem twojego katalogu domowego.

Jeśli potrzebujesz go uruchomić z innej lokalizacji, po prostu użyj cdw skrypcie, aby przejść do tej lokalizacji.

ssmtpprawdopodobnie nie cronjest domyślną ŚCIEŻKĄ (z założenia jest bardzo wąska na większości platform). Możesz albo podać pełną ścieżkę do ssmtpskryptu, albo jawnie ustawić PATH w a) pliku crontab, który będzie dostępny dla wszystkich twoich skryptów, lub b) w każdym skrypcie.

Sprawdź ten wątek, w jaki sposób możesz łatwo dowiedzieć się, jakie jest środowisko crona, jest o wiele mniej niż przyzwyczajone w interaktywnej powłoce. Najlepiej jest założyć, że nic nie zostało ustawione i jawnie ustawić to samodzielnie.

Domyślnym katalogiem roboczym do cronwykonywania zadania jest zazwyczaj katalog domowy /home/your-user-name.

Przyjęcie @Kusalananda doskonałego komentarza.

Niektóre osoby sugerowały lub łączyły się z tym, ale najlepszym sposobem, aby się tego dowiedzieć, ponieważ nie mogę tego znaleźć w dokumentacji dla mojego dystrybucji, jest dodanie tego do crona

* * * * * echo $PATH > /tmp/lolcronjobs

W moim przypadku ubuntu domyślnie używa tylko tego, /usr/bin:/binco spowodowało kilka problemów.