Servo32 0 Zgłoś post Napisano Czerwiec 6, 2017 Serwer chodzi na Ubuntu 14.04 i nginx. Problem dotyczny Crona, chcę zacząć zadanie (crontab) przez plik - cron.txt, jego zawartość: * * * * * /usr/bin/php /var/www/html/test.php >> /var/log/cron.log Jeśli odpalę crona jako root w konsoli: crontab /var/www/html/cron.txt To wszystko działa prawidłowo - skrypt test.php wykonuje się co minutę. Ale gdy odpalę go przez skrypt PHP (wywołany przez przeglądarkę, o to mi właśnie chodzi, żeby tak to działało) to zadanie dopisywane jest użytkownikowi www-data i cron wtedy nie działa. Gdy sprawdzam poleceniem: crontab -l -u www-data To wyświetla dodane zadanie prawidłowo, ale go nie wykonuje. Czy ma ktoś może jakiś pomysł jak zmusić crona do wykonywania również zadań www-data? Udostępnij ten post Link to postu Udostępnij na innych stronach
Rolej 58 Zgłoś post Napisano Czerwiec 6, 2017 sudo -u www-data crontab -e W ten sposób dodajesz do crona dla www-data? Udostępnij ten post Link to postu Udostępnij na innych stronach
Servo32 0 Zgłoś post Napisano Czerwiec 6, 2017 Jak napisałem wyżej, chodzi o dodawanie do crona za pomocą PHP, dokładniej: exec('crontab /var/www/html/cron.txt'); Po wykonaniu tego, dodaje zadanie dla www-data, jest ono widoczne po wpisaniu: crontab -l -u www-data Ale niestety go nie wykonuje. Udostępnij ten post Link to postu Udostępnij na innych stronach
is_wm 287 Zgłoś post Napisano Czerwiec 6, 2017 crontab -> /usr/bin/crontab ? Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Czerwiec 6, 2017 (edytowany) W cronie musisz albo sam inicjalizować PATH (unikać), albo podawać ścieżki absolutne. Więc nie execowe "crontab", tylko robisz "which crontab" i używasz ścieżki absolutnej, np. tak jak podał is_wm: /usr/bin/crontab. Edytowano Czerwiec 6, 2017 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
kafi 2425 Zgłoś post Napisano Czerwiec 6, 2017 W cronie musisz albo sam inicjalizować PATH (unikać), albo podawać ścieżki absolutne. Więc nie execowe "crontab", tylko robisz "which crontab" i używasz ścieżki absolutnej, np. tak jak podał is_wm: /usr/bin/crontab. Yyy... Ale w zadaniach cron są ścieżki bezwzględne, a phpowy skrypt tylko poleceniem "crontab" aktualizuje tablicę cron użytkownika www-data i robi to raczej skutecznie, skoro crontab -l -u wyświetla wpisy poprawnie. Przyczyna nieuruchamiania tych zadań jest prozaiczna - w Debianie i pochodnych (bo użytkownik www-data to wymysł debianowy) użytkownik www-data ma ustawiony shell nologin - który blokuje m.in. wykonywanie zadań via crontab. Rozwiązania problemu są trzy: - pierwsze, z piekła rodem, to zmiana shella na /bin/bash - ale hmm... to zło - drugie - nadanie jakiemuś "zwykłemu" użytkownikowi uprawnień SUDO jako www-data i wykonywanie w crontabie polecenia sudo -u www-data polecenie - trzecie - najbardziej zalecane to zrezygnować z wykonywania zadań z uprawnieniami www-data. W cronie musisz albo sam inicjalizować PATH (unikać), albo podawać ścieżki absolutne. Więc nie execowe "crontab", tylko robisz "which crontab" i używasz ścieżki absolutnej, np. tak jak podał is_wm: /usr/bin/crontab. Yyy... Ale w zadaniach cron są ścieżki bezwzględne, a phpowy skrypt tylko poleceniem "crontab" aktualizuje tablicę cron użytkownika www-data i robi to raczej skutecznie, skoro crontab -l -u wyświetla wpisy poprawnie. Przyczyna nieuruchamiania tych zadań jest prozaiczna - w Debianie i pochodnych (bo użytkownik www-data to wymysł debianowy) użytkownik www-data ma ustawiony shell nologin - który blokuje m.in. wykonywanie zadań via crontab. Rozwiązania problemu są trzy: - pierwsze, z piekła rodem, to zmiana shella na /bin/bash - ale hmm... to zło - drugie - nadanie jakiemuś "zwykłemu" użytkownikowi uprawnień SUDO jako www-data i wykonywanie w crontabie polecenia sudo -u www-data polecenie - trzecie - najbardziej zalecane to zrezygnować z wykonywania zadań z uprawnieniami www-data. Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Czerwiec 6, 2017 (edytowany) Można jeszcze czwartym rozwiązaniem pojechać, nieco na około: wykonywać skrypt PHP przez np. CURL z uprawnieniami roota. Można dodatkowo go zabezpieczyć, żeby dopuszczał tylko 127.0.0.1. Wtedy root sobie CURLem wykonuje example.com/cron.php, a to już odpala się z www-data. Osobiście preferuję to rozwiązanie zamiast innego usera czy całkowitej rezygnacji. Edytowano Czerwiec 6, 2017 przez Archi (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
LuCek6 0 Zgłoś post Napisano Luty 11, 2018 a jesteś pewien że www-data ma prawo do tego skryptu? Udostępnij ten post Link to postu Udostępnij na innych stronach