Cron
Dodane przez Grzegorz Mac on 24 May 2018 08:01:29
|
|
Cron - mechanizm okresowego uruchamiania poleceń na serwerze Opisane na tej stronie:
1. Ogólny mechanizm dodawania zadań Cron-a:
Wygląd menu zadań Cron-a: 2. Ustawianie czasu uruchomienia zadania Jako czasy wykonywania zadania domyślnie ustawione są znaki gwiazdek („*”) które oznaczają uruchamianie zadania co minutę - należy to zmienić aby nie przeciążać serwera.
Czas uruchamiania zadań crona można ustawiać również inaczej - nie mniej powyższe nadają się do zastosowania w praktycznie każdym przypadku. 3. Jaką komendą uruchamiać zadanie? Kod, który ma być uruchamiany za pomocą crona, można wywoływać w różny sposób, lecz za każdym razem konieczne jest uzupełnienie pola Komenda we właściwy sposób dostosowany do rodzaju uruchamianego kodu Przykłady komendy uruchamiającej kod PHP lokalnie na serwerze: php /home/TWÓJ_LOGIN/nazwapliku.php php /home/TWÓJ_LOGIN/domains/NAZWA_DOMENY/public_html/cron.php gdzie zamiast TWÓJ_LOGIN będzie login konta używany do logowania w panelu Direct Admin, do którego dodawane jest to zadanie, a NAZWA_DOMENY to nazwa domeny podpiętej pod konto. Jeśli zadanie crona wygeneruje jakąkolwiek treść (np. błędy wykonania kodu lub samej komendy), która normalnie zostałaby zwrócona/wypisana (tak jak normalne wyniki poleceń zwracane na terminal), wszystko to zostanie wysłane na główną skrzynkę mailową - do której można się zalogować tak jak do każdej innej skrzynki mailowej, lecz logując się przy pomocy danych do logowania do Direct Admina. Jeśli zadanie crona generuje jakąkolwiek treść, ale nie ma ona być gdziekolwiek wysyłana, na końcu komendy dodaje się: >>/dev/null 2>&1 (będące również efektem naciśnięcia przycisku "Bez generowania maili o błędach itp" w menu zadań crona) Jeśli zadanie będzie generować treść, ale mail główny nie będzie regularnie czyszczony przez użytkownika, po pewnym czasie komunikaty zapełnią przetrzeń konta. Dlatego zalecamy dodanie powyższego „przekierowania do kosza” na końcu komendy.
Jeżeli chcemy uruchomić kod znajdujący się na innym serwerze używamy: lynx -dump http://domena/plik.php Alternatywnie, zamiast lynxa, można użyć wget-a: wget -q -O - http://domena/plik.php gdzie http://domena/plik.php to adres normalnie wpisywany w przeglądarce WWW. Jeśli polecenie wget lub lynx nie działa wywołane krótką nazwą, trzeba użyć pełnej: /usr/bin/wget Polecenie php uruchamia automatycznie domyślną wersję PHP na serwerze (na nowych 5.3, na starszych 5.2). /usr/local/bin/php4 (na starszych serwerach ścieżki mogą się różnić) Między nazwą polecenia (np php) i nazwą kodu nim uruchamianego zawsze musi być znak spacji. Aby zadania się nie duplikowały, gdy jedno wykonuje się tak długo, że nie zdąży się zakończyć przed porą uruchomienia kolejny raz, można użyć dodatkowej komendy flock, podanej jako pierwszej w treści komendy. Nie zezwoli ona na uruchomienie kolejnego zadania jeżeli poprzednie się nie zakończy i jeszcze działa. Jest to zalecane za każdym razem dla zadań które muszą czekać na wykonanie czasochłonnej operacji, zwłaszcza tam gdzie pobierane są dane z zewnętrznych serwerów, ponieważ zapobiegnie przeciążeniom. Przykład komendy: flock -n /tmp/cron1234 lynx -dump http://domena/plik.php gdzie cron1234 można zastąpić dowolnym ciągiem znaków tak aby każde zdanie miało swoją unikalną nazwę dla flock-a 4. Jak sprawdzić czy Cron działa? Należy rozróżnić działanie Cron-a od działania komendy uruchamianej przez niego. Czy sam Cron działa sprawdzić można dodając zadanie: date i sprawdzając skrzynkę główną konta (dane do logowania jak do Direct Admina) lub: date >> /home/TWÓJ_LOGIN/crontest.txt i sprawdzając przez FTP/SSH czy istnieje plik i jaka jest jego zawartość 5. Jak sprawdzić czy działa zadanie dodane do Cron-a? Można to sprawdzić łatwo tylko jeśli zadanie generuje jakiekolwiek komunikaty potwierdzające jego wykonanie lub napotkanie błędów. Jeśli zadanie nie wykonuje się poprawnie i zwraca komunikat błędu, można usunąć >>/dev/null 2>&1 z komendy i sprawdzić co przychodzi na maila głównego. Alternatywnie można zamienić >>/dev/null 2>&1 na: >> /home/TWÓJ_LOGIN/wynik_zadania.txt 2>&1 i sprawdzając przez FTP/SSH podobnie jak dla sprawdzania samego Cron-a Jeśli błędy nie są generowane przez uruchamiany kod, pozostaje ręczna analiza przebiegu pracy kodu i to użytkownik musi zrobić samodzielnie. 6. Pomiar czasu pracy zadania dodanego do Cron-a Czas pracy kodu uruchamianego przez Cron-a można mierzyć w ten sam sposób, jaki jest możliwy bezpośrednio z terminala - za pomocą polecenia time, przykład komendy: time php /home/TWÓJ_LOGIN/nazwapliku.php wynik pracy polecenia time w takim przypadku zostanie przesłany na maila głównego.
7. Znane problemy Kod uruchamiany przez stronę www działa, ale nie działa wywołanie przez crona - zwracane są komunikaty o nieistniejących plikach i/lub błędnych ścieżkach: Przyczyną jest stosowanie względnych ścieżek do plików w uruchamianym kodzie bez jednoczesnej weryfikacji lokalizacji względem uruchamianego kodu. W przypadku wywołań stron, katalog z którego uruchamiany jest kod jest tym, w którym się on znajduje, a w przypadku Cron-a, jest nim zawsze główny katalog konta. Dlatego przez wywołaniem kodu poleceniem uruchamiającym go lokalnie, najlepiej jest dodać dodatkowe polecenie "przechodzące do katalogu z kodem" lub adekwatnie zmienić istniejące wg schematu: cd KATALOG_Z_PLIKIEM && [wywołanie] gdzie KATALOG_Z_PLIKIEM to lokalizacja w której znajduje się kod, przykład: gdy normalnie jest: php domains/nazwadomeny/public_html/cron.php zamieniamy na: cd domains/nazwadomeny/public_html && php cron.php Alternatywnym rozwiązaniem jest rezygnacja z względnych ściężek w kodzie lub inteligentna kontrola tych ścieżek na podstawie lokalizacji uruchamianego pliku. | |
|
wget -q -F -O - http://TwojaDomena.pl/cron1.php >/dev/null 2>&1
nie bedziemy informowani o ewentualnych bledach i nie beda tworzone pliki smieci.