Kopia zapasowa, która ma powstawać co noc. Wysyłka zaległych wiadomości ze sklepu. Aktualizacja stanów magazynowych z pliku hurtowni. Wszystkie te czynności łączy jedno: ktoś musi je uruchomić o określonej porze, a człowiek o tym zapomina. Serwer nie zapomina, o ile dostanie zadanie cron, czyli polecenie z przypisanym harmonogramem.
Ta instrukcja jest przeznaczona dla właścicieli firm i osób opiekujących się stroną, które mają dostęp do panelu hostingu, ale nie są programistami. Samo dodanie zadania to kilka pól w formularzu. Trudność leży gdzie indziej: w pięciu polach harmonogramu, które łatwo pomylić, w ścieżce do pliku, która musi być dokładna, oraz w ograniczeniach, jakie nakłada konkretny hosting.
Po lekturze czytelnik będzie umiał zapisać dowolną stałą porę w składni cron, ułożyć poprawne polecenie, dodać zadanie w najpopularniejszych panelach, sprawdzić, czy naprawdę się wykonało, oraz znaleźć przyczynę, gdy serwer milczy.
Czym jest zadanie cron i co przygotować przed jego dodaniem?
Cron to usługa działająca na serwerze, która co minutę sprawdza listę zaplanowanych zadań i uruchamia te, na które przyszła pora. Każde zadanie składa się z dwóch części: harmonogramu (kiedy) i polecenia (co). Panel hostingu jest tylko wygodnym formularzem do edycji tej listy, dlatego zasady są wszędzie podobne, nawet jeśli pola nazywają się inaczej.
W firmowej stronie cron przydaje się najczęściej do pięciu rzeczy: nocnych kopii zapasowych, cyklicznego importu lub eksportu danych, wysyłki zaplanowanych wiadomości, czyszczenia plików tymczasowych oraz regularnego uruchamiania harmonogramu WordPressa, który bez tego działa nieregularnie. Jeżeli celem jest kopia, przed ustawieniem harmonogramu dobrze jest przeczytać, jak powinna wyglądać kopia zapasowa WordPressa, którą da się odtworzyć, bo samo zadanie cron nie gwarantuje, że plik kopii jest kompletny.
Zanim otworzy się formularz w panelu, trzeba zebrać kilka informacji. Bez nich zadanie zostanie dodane, ale nie zadziała.
- Ustalenie, co dokładnie ma zostać uruchomione: plik skryptu na serwerze (na przykład
import.php) albo adres strony, który wystarczy wywołać. - Odszukanie pełnej ścieżki do tego pliku. W menedżerze plików panelu albo w programie do połączeń SFTP widać ją od katalogu domowego konta, na przykład
/home/nazwakonta/public_html/import.php. - Sprawdzenie w pomocy hostingu, jaką ścieżką wywołuje się PHP z wiersza poleceń i w jakiej wersji. Na wielu serwerach jest kilka wersji obok siebie i każda ma własną ścieżkę.
- Sprawdzenie strefy czasowej serwera. Harmonogram liczy się według zegara serwera, a nie komputera, z którego dodaje się zadanie.
- Sprawdzenie ograniczeń konta: najmniejszego dozwolonego odstępu między uruchomieniami, maksymalnego czasu pracy skryptu i liczby zadań. Te dane podaje dokumentacja hostingu albo opis pakietu.
- Jednorazowe ręczne uruchomienie skryptu, zanim trafi do harmonogramu. Zadanie cron powtarza tylko to, co działa; nie naprawi skryptu, który kończy się błędem.
Ograniczenia z punktu piątego bywają pomijane, a to one najczęściej decydują, czy plan da się zrealizować. Jak je odczytać z oferty, opisałem we wpisie o tym, jak czytać parametry hostingu i rozpoznać realne ograniczenia konta.
Jak zapisać stałą porę w pięciu polach harmonogramu?
Harmonogram cron to pięć pól, zawsze w tej samej kolejności: minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia. Zadanie uruchamia się w chwili, gdy bieżący czas serwera pasuje do wszystkich pól jednocześnie. Gwiazdka w polu oznacza „każda wartość”, więc pięć gwiazdek to zadanie uruchamiane co minutę.

Zakresy wartości są stałe: minuta od 0 do 59, godzina od 0 do 23, dzień miesiąca od 1 do 31, miesiąc od 1 do 12, dzień tygodnia od 0 do 7, przy czym zarówno 0, jak i 7 oznaczają niedzielę, a 1 to poniedziałek. Godziny zapisuje się w układzie całodobowym, więc trzecia po południu to 15.
Jakie znaki są dozwolone w polach?
Oprócz liczby i gwiazdki stosuje się trzy znaki. Przecinek łączy kilka wartości: 1,15 w polu dnia miesiąca oznacza pierwszy i piętnasty dzień. Dywiz wyznacza zakres: 1-5 w polu dnia tygodnia to dni od poniedziałku do piątku. Ukośnik wyznacza odstęp: */15 w polu minut oznacza co piętnaście minut, licząc od pełnej godziny.
Najczęstszy błąd początkujących to gwiazdka w polu minut przy zadaniu, które miało działać raz dziennie. Zapis * 3 * * * nie oznacza „o trzeciej”, tylko „w każdej minucie między 3:00 a 3:59”, czyli sześćdziesiąt uruchomień. Stała pora zawsze wymaga konkretnej liczby w polu minut.
Gotowe zapisy dla typowych pór
Poniższe wiersze można przepisać do formularza pole po polu, zmieniając tylko godzinę i minutę.
15 3 * * *– codziennie o 3:15.0 6 * * 1– w każdy poniedziałek o 6:00.0 7 * * 1-5– w dni robocze o 7:00.30 4 1 * *– pierwszego dnia każdego miesiąca o 4:30.0 8,14 * * *– dwa razy dziennie, o 8:00 i o 14:00.*/15 * * * *– co piętnaście minut przez całą dobę.
Na co uważać przy dniu miesiąca i dniu tygodnia?
Te dwa pola zachowują się inaczej niż pozostałe. Jeżeli w obu wpisano konkretne wartości, zadanie uruchomi się, gdy pasuje którekolwiek z nich. Zapis 0 6 13 * 5 nie oznacza więc „w piątek trzynastego”, tylko „trzynastego dnia miesiąca oraz w każdy piątek”. W praktyce jedno z tych pól powinno zostać gwiazdką.
Druga pułapka to dni, których nie ma w każdym miesiącu. Zadanie ustawione na 31. dzień nie uruchomi się w miesiącach krótszych. Jeśli chodzi o rozliczenie miesiąca, bezpieczniej zaplanować je na pierwszy dzień następnego.
Jaką godzinę wybrać?
Ciężkie zadania, takie jak kopia lub import, planuje się na porę najmniejszego ruchu na stronie, zwykle w nocy. Radzę jednak omijać przedział między 2:00 a 3:00 czasu polskiego. W noc zmiany czasu ta godzina raz w roku nie występuje, a raz występuje dwukrotnie, więc zależnie od serwera zadanie może zostać pominięte albo wykonane dwa razy.
Dobrym zwyczajem jest też wybór „nierównej” minuty, na przykład 3:17 zamiast 3:00. Na hostingu współdzielonym o pełnych godzinach uruchamia się najwięcej zadań innych klientów i serwer bywa wtedy najbardziej obciążony.
Jak ułożyć polecenie, które serwer ma wykonać?
Polecenie to wiersz tekstu, który serwer wykonuje tak, jakby ktoś wpisał go w konsoli. Cron uruchamia go w bardzo ubogim środowisku: bez znajomości katalogu strony i bez większości ustawień, z których korzysta zalogowany użytkownik. Dlatego w poleceniu podaje się pełne ścieżki, zarówno do programu, jak i do pliku. Dokumentacja cPanel mówi o tym wprost: należy wskazać ścieżkę bezwzględną do polecenia.
Uruchomienie skryptu PHP z dysku serwera
Najpewniejszy sposób to wywołanie interpretera PHP z plikiem jako argumentem. Wzór wygląda tak:
/usr/local/bin/php /home/nazwakonta/public_html/import.php
Pierwsza część to ścieżka do PHP, druga to ścieżka do skryptu. Obie trzeba dopasować do własnego konta. Ścieżka do PHP różni się między firmami hostingowymi i między wersjami języka, więc nie należy jej zgadywać, tylko odszukać w pomocy dostawcy pod hasłem „PHP w zadaniach cron” lub „PHP CLI”.
Skrypt uruchomiony w ten sposób nie przechodzi przez serwer WWW. Ma to dwie konsekwencje. Po pierwsze, plik może leżeć poza katalogiem publicznym, co jest bezpieczniejsze, bo nikt nie wywoła go z przeglądarki. Po drugie, parametry dopisane po znaku zapytania, takie jak import.php?tryb=pelny, nie zadziałają, ponieważ są częścią adresu strony, a nie ścieżki do pliku.
Wywołanie adresu strony
Niektóre wtyczki i systemy sklepowe podają gotowy adres, który ma być odwiedzany cyklicznie. Wtedy polecenie korzysta z programu pobierającego strony. Dokumentacja WordPressa podaje wzór z programem wget:
wget --delete-after https://adres-strony.pl/wp-cron.php
Opcja --delete-after sprawia, że pobrana odpowiedź nie zostaje na dysku. Bez niej każdy przebieg zostawiałby na koncie kolejny plik. Ta metoda obciąża serwer WWW tak samo jak wizyta zwykłego użytkownika i podlega jego limitom czasu, dlatego dla długich operacji lepsza jest metoda pierwsza.
Jeżeli adres zawiera tajny klucz (często wymagają tego wtyczki do kopii lub importu), trzeba pamiętać, że polecenie bywa widoczne w wiadomościach z raportem i w dziennikach. Taki klucz należy traktować jak hasło i nie przesyłać go dalej w zrzutach ekranu.
Co zrobić z tym, co skrypt wypisuje?
Wszystko, co polecenie wypisze na ekran, cron próbuje wysłać pocztą na adres ustawiony w panelu. Na etapie testów jest to bardzo pomocne, bo w wiadomości widać treść błędu. Później, przy zadaniu uruchamianym często, skrzynka zapełnia się setkami wiadomości.
Są dwa rozwiązania. Pierwsze to wyciszenie zadania przez dopisanie na końcu polecenia fragmentu >/dev/null 2>&1, który kieruje cały wynik donikąd. Drugie, moim zdaniem lepsze, to zapis wyniku do pliku dziennika, na przykład przez dopisanie >> /home/nazwakonta/logi/import.log 2>&1. Zadanie nie zapełnia wtedy skrzynki, a w razie kłopotów jest gdzie zajrzeć.
Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: ustalę ścieżki i ograniczenia konta, ułożę polecenie z harmonogramem, dodam zadanie w panelu i sprawdzę w dziennikach, że uruchamia się o właściwej porze.
Jak dodać zadanie cron w panelu cPanel?
W cPanel służy do tego narzędzie „Cron Jobs” w grupie „Advanced”. Nazwy podaję za angielską dokumentacją cPanel; w panelu przełączonym na język polski będą przetłumaczone, ale układ formularza pozostaje taki sam. Dostawca hostingu może tę funkcję wyłączyć w tańszych pakietach. Jeśli narzędzia nie ma na liście, trzeba zapytać o nie obsługę.
- Po zalogowaniu do cPanel należy otworzyć narzędzie „Cron Jobs”.
- W części „Cron Email” w polu „Email” wpisuje się adres, na który mają trafiać wyniki zadań, i zatwierdza przyciskiem „Update Email”. Na czas testów powinien to być adres, który ktoś faktycznie czyta.
- W części dodawania zadania można rozwinąć listę „Common Settings” i wskazać jeden z gotowych odstępów, na przykład „Once Per Hour(0 * * * *)”. Panel sam wypełni wtedy pięć pól.
- Dla własnej stałej pory wypełnia się ręcznie pola „Minute”, „Hour”, „Day”, „Month” i „Weekday”. Dla zadania codziennie o 3:15 będą to kolejno: 15, 3, gwiazdka, gwiazdka, gwiazdka.
- W polu „Command” wpisuje się przygotowane wcześniej polecenie z pełnymi ścieżkami.
- Zadanie zapisuje przycisk „Add New Cron Job”. Panel wyświetla komunikat o powodzeniu, a zadanie pojawia się w tabeli „Current Cron Jobs”.

Wszystkie pięć pól harmonogramu i pole polecenia muszą być wypełnione, inaczej panel nie przyjmie zadania. Zmianę wprowadza się przyciskiem „Edit” przy wybranym wierszu tabeli i zatwierdza przyciskiem „Edit Line”. Usunięcie wymaga dwóch kliknięć „Delete”: przy zadaniu i w potwierdzeniu.
Dokumentacja cPanel zawiera dwa ostrzeżenia, które przytaczam, bo dotyczą realnych strat. Pierwsze: zadania nie powinny być uruchamiane zbyt często, ponieważ serwer może rozpocząć kolejny przebieg, zanim skończy się poprzedni, a nakładające się przebiegi pogarszają wydajność. Drugie: szczególną ostrożność trzeba zachować przy poleceniu rm, które usuwa pliki. Błędnie podane opcje mogą usunąć dane całego katalogu domowego. Jeżeli zadanie ma coś usuwać, przed dodaniem go do harmonogramu konieczna jest aktualna kopia konta.
Gdy zadanie uruchamia własny skrypt powłoki (plik z rozszerzeniem .sh), plik musi mieć nadane prawo wykonywania. Uprawnienia zmienia się w menedżerze plików panelu. Skryptów PHP wywoływanych przez interpreter, jak we wzorze wyżej, ten wymóg nie dotyczy.
Jak dodać zadanie w panelu OVHcloud?
Na hostingu WWW w OVHcloud formularz działa inaczej niż w cPanel. Nie wpisuje się pełnego polecenia, tylko wskazuje plik skryptu i wersję języka, a harmonogram ustawia w osobnym kroku. Według polskiej dokumentacji OVHcloud przebiega to następująco.
- W Panelu klienta należy przejść do działu „Web Cloud”, następnie „Hosting” i wskazać właściwy hosting WWW.
- Trzeba kliknąć zakładkę „Więcej”, a potem „Cron”. Pojawi się tabela zaplanowanych zadań.
- Po prawej stronie znajduje się przycisk „Dodaj zadanie”, który otwiera okno ustawień.
- W polu „Zamówienie do wykonania” podaje się ścieżkę do pliku ze skryptem, w dokumentacji pokazaną na przykładzie
www/jobs/cron.php. W polu „Język” wskazuje się wersję PHP, której używa skrypt. - Opcja „Aktywacja” decyduje, czy zadanie ruszy od razu, czy zostanie włączone później. W polu „Logi na e-mail” wskazuje się kontakt lub inny adres, na który trafi raport w razie błędu, a pole „Opis” pozwala nazwać zadanie. Po wypełnieniu należy kliknąć „Dalej”.
- Częstotliwość ustawia się w jednym z dwóch trybów. „Tryb prosty” to rozwijane listy z godziną, dniami miesiąca, dniami tygodnia i miesiącami. „Tryb eksperta” przyjmuje wartości liczbowe jak w składni cron. Między trybami można się przełączać. Krok kończy przycisk „Dalej”.
- Podsumowanie pokazuje ustawione parametry razem z zapisem harmonogramu. Jeśli wszystko się zgadza, należy kliknąć „Zatwierdź”. Dokumentacja podaje, że zadanie jest gotowe po kilku minutach.
Zmiana lub usunięcie zadania odbywa się w tej samej tabeli: przycisk z trzema kropkami po prawej stronie wiersza otwiera pozycje „Zmodyfikuj” oraz „Usuń”.
Ograniczenia, które trzeba znać przed zaplanowaniem pory
Na tym hostingu pole minut jest wyłączone. Zadanie może się uruchamiać najwyżej raz na godzinę, a dokładną minutę wyznacza system, nie użytkownik. Stała pora oznacza tu więc „w ciągu wskazanej godziny”, a nie „co do minuty”. Dla kopii zapasowej nie ma to znaczenia, dla wysyłki o ściśle określonej porze już tak.

Pozostałe ograniczenia z dokumentacji OVHcloud są równie konkretne. Skrypt może pracować do 60 minut, po czym system go zatrzymuje. Zadanie może wygenerować najwyżej 5 MB danych wyjściowych. Zmiennych nie przekazuje się w ścieżce, muszą być ustawione wewnątrz skryptu. Skrypt, który kończy się błędem, zostaje automatycznie wyłączony po 10 nieudanych próbach i dopiero wtedy wysyłany jest raport, a same raporty trafiają na skrzynkę raz dziennie, w godzinach nocnych.
Wyłączone zadanie nie wraca do pracy samo. Po poprawieniu skryptu trzeba je ponownie włączyć w tabeli, przez przycisk z trzema kropkami i pozycję „Zmodyfikuj”.
Jak znaleźć zadania cron w DirectAdmin i w panelach autorskich?
Wiele polskich firm hostingowych korzysta z DirectAdmin albo z własnego panelu. Nazwy pozycji w menu zależą od wersji i od ustawionej skórki, dlatego nie podaję ich co do litery. Narzędzia należy szukać pod hasłami „Cron”, „Zadania cron”, „Zadania cykliczne” lub „Harmonogram zadań”, najczęściej w grupie funkcji zaawansowanych, a najszybciej przez wyszukiwarkę w panelu.
Formularz niemal zawsze zawiera te same elementy co w cPanel: pięć pól harmonogramu, pole polecenia i przycisk zapisu. Różnice dotyczą trzech rzeczy, które trzeba sprawdzić w pomocy konkretnego dostawcy:
- czy w polu polecenia wpisuje się pełne polecenie, samą ścieżkę do pliku, czy adres strony do wywołania,
- jaki jest najmniejszy dozwolony odstęp między uruchomieniami i ile zadań można dodać na jednym koncie,
- gdzie ustawia się adres do powiadomień i czy panel pokazuje historię uruchomień.
Jeżeli panel w ogóle nie ma takiego narzędzia, funkcja może być niedostępna w danym pakiecie. Wtedy pozostaje zmiana pakietu albo zapytanie obsługi, czy doda zadanie po swojej stronie. Odradzam korzystanie z przypadkowych serwisów zewnętrznych, które cyklicznie odwiedzają podany adres, jeśli ten adres zawiera tajny klucz albo uruchamia operację na danych klientów. Klucz trafia wtedy do firmy trzeciej, nad którą właściciel strony nie ma kontroli.
Gdy dostęp do panelu ma również wykonawca strony, po zakończeniu współpracy listę zadań trzeba przejrzeć tak samo jak konta dostępowe, o czym piszę we wpisie o tym, jak utworzyć konto FTP dla wykonawcy i odebrać je po zakończeniu prac.
Jak zastąpić wbudowany harmonogram WordPressa zadaniem cron?
WordPress ma własny mechanizm zadań, zwany WP-Cron. Odpowiada on za publikację zaplanowanych wpisów, sprawdzanie aktualizacji, a także za zadania wtyczek, w tym kopie i wysyłkę wiadomości ze sklepu. Jego słabość polega na tym, że nie działa w sposób ciągły: sprawdza listę zadań dopiero przy wczytaniu strony przez odwiedzającego.
Skutki są dwa. Na stronie z małym ruchem wpis zaplanowany na 6:00 może ukazać się dopiero wtedy, gdy ktoś wejdzie na stronę. Na stronie z dużym ruchem sprawdzanie odbywa się przy każdej wizycie i zajmuje zasoby serwera. Dokumentacja WordPressa opisuje rozwiązanie: wyłączyć uruchamianie przy wizytach i zlecić je zadaniu systemowemu.
- Wykonanie kopii pliku
wp-config.php, który znajduje się w głównym katalogu WordPressa. - Otwarcie pliku w edytorze menedżera plików i dopisanie nad wierszem z komentarzem kończącym edycję (zaczyna się od słów „That’s all, stop editing”) wiersza:
define( 'DISABLE_WP_CRON', true ); - Zapisanie pliku i sprawdzenie, czy strona nadal się wczytuje. Brak średnika lub apostrofu w tym pliku wyłącza całą stronę, dlatego kopia z punktu pierwszego jest konieczna.
- Dodanie w panelu hostingu zadania cron z harmonogramem
*/15 * * * *i poleceniemwget --delete-after https://adres-strony.pl/wp-cron.php, z własnym adresem strony. - Zaplanowanie testowego wpisu na porę za kilkanaście minut i sprawdzenie, czy opublikował się bez niczyjej wizyty na stronie.
Dokumentacja WordPressa nie narzuca odstępu i pozostawia go do decyzji administratora; piętnaście minut pochodzi z podanego tam przykładu i dla większości stron firmowych jest rozsądne. Sklep z wieloma zamówieniami może potrzebować krótszego odstępu, o ile hosting na to pozwala. Tam, gdzie najkrótszy odstęp to godzina, zaplanowane wpisy będą się ukazywać z opóźnieniem do godziny i trzeba to uwzględnić.
Kolejność kroków ma znaczenie. Jeśli wiersz w wp-config.php zostanie dopisany, a zadanie w panelu nie powstanie albo nie zadziała, harmonogram WordPressa zatrzyma się całkowicie: bez publikacji, bez kopii, bez wiadomości. Jeżeli strona po tej zmianie nadal działa ociężale, przyczyna leży gdzie indziej i trzeba ustalić, co naprawdę spowalnia WordPressa.
Po czym poznać, że zadanie naprawdę się wykonało?
Pojawienie się zadania w tabeli panelu oznacza tylko, że zostało zapisane. O tym, czy działa, świadczą dopiero ślady jego pracy. Pierwszego uruchomienia nie należy zostawiać na noc: na czas testu ustawia się porę przypadającą za kilka minut, a po potwierdzeniu wyniku zmienia na docelową.
Są cztery źródła potwierdzenia i dobrze jest skorzystać przynajmniej z dwóch.
- Efekt pracy skryptu: nowy plik kopii z właściwą godziną utworzenia, zaktualizowane stany w sklepie, opublikowany wpis.
- Wiadomość z wynikiem zadania, jeśli w panelu ustawiono adres do powiadomień, a polecenie nie zostało wyciszone.
- Własny plik dziennika, do którego polecenie dopisuje wynik każdego przebiegu.
- Dziennik zadań prowadzony przez hosting, o ile panel go udostępnia.
W OVHcloud dzienniki hostingu mają osobną kategorię „CRON”. Poprawny przebieg kończy się wpisem z oznaczeniem exitcode: 0. Wpis z komunikatem „not found” i kodem 255 oznacza, że pod podaną ścieżką nie ma pliku. Komunikat o przerwaniu zadania z powodu przekroczenia 3600 sekund oznacza, że skrypt pracował dłużej niż dozwoloną godzinę.
Brak wiadomości nie jest dowodem powodzenia. Skrypt, który nic nie wypisuje, nie wywoła żadnej wiadomości ani wtedy, gdy się udał, ani wtedy, gdy zakończył pracę w połowie. Dlatego przy zadaniach ważnych dla firmy, zwłaszcza kopiach, radzę raz w miesiącu zajrzeć do katalogu z wynikami i sprawdzić datę oraz rozmiar ostatniego pliku.
Zadanie się nie uruchamia. Jak znaleźć przyczynę?
Przyczyn jest kilka i dają się sprawdzić po kolei, od najczęstszej. Na czas szukania trzeba włączyć powiadomienia pocztą i usunąć z polecenia fragment wyciszający, bo to treść błędu najszybciej prowadzi do rozwiązania.
Błędna ścieżka do pliku lub do PHP
To przyczyna najczęstsza. Objawem jest komunikat o braku pliku albo o nieznanym poleceniu. Ścieżkę należy skopiować z menedżera plików zamiast przepisywać ręcznie i zwrócić uwagę na wielkość liter, bo serwer rozróżnia Import.php i import.php. Jeśli komunikat dotyczy samego PHP, trzeba ponownie sprawdzić w pomocy hostingu ścieżkę do interpretera.
Skrypt działa w przeglądarce, a w cron nie
Skrypt uruchomiony przez cron startuje w innym katalogu roboczym niż ten, w którym leży. Jeżeli wczytuje inne pliki przez ścieżki względne, nie znajduje ich. Dokumentacja OVHcloud zaleca stosowanie w skryptach wyłącznie ścieżek bezwzględnych. Poprawka należy do autora skryptu; od strony panelu pomaga czasem poprzedzenie polecenia przejściem do katalogu: cd /home/nazwakonta/public_html && /usr/local/bin/php import.php.
Drugim powodem bywa inna wersja PHP. Strona może działać na nowszej wersji ustawionej w panelu, a polecenie w cron wywoływać starszą, domyślną. Skrypt kończy się wtedy błędem składni, którego w przeglądarce nie widać.
Harmonogram oznacza co innego, niż zakładano
Jeśli zadanie uruchamia się, ale o złej porze, trzeba wrócić do pięciu pól. Typowe pomyłki to zamiana miejscami minuty i godziny, gwiazdka w polu minut, wypełnione jednocześnie pola dnia miesiąca i dnia tygodnia oraz pominięcie różnicy między czasem serwera a czasem polskim. Przesunięcie o równą godzinę lub dwie prawie zawsze oznacza inną strefę czasową serwera.
Brak uprawnień
Skrypt powłoki bez prawa wykonywania nie uruchomi się, podobnie jak skrypt, który próbuje zapisać plik w katalogu bez prawa zapisu. W OVHcloud problem z uprawnieniami lub z plikiem konfiguracyjnym .ovhconfig objawia się w dzienniku komunikatem, że zadania nie udało się zainicjować z nieznanego powodu, z kodem 255.
Przekroczony limit czasu lub wyłączenie przez hosting
Zadanie, które ruszało i przestało, mogło zostać wyłączone automatycznie po serii błędów albo jest przerywane po przekroczeniu czasu. Długą operację trzeba wtedy podzielić na mniejsze porcje, na przykład import po kilkaset produktów w kilku przebiegach, zamiast zwiększać częstotliwość jednego ciężkiego zadania.
Zadanie w WordPressie nadal się spóźnia
Jeśli po przeniesieniu harmonogramu WordPressa do cron wpisy wciąż ukazują się z opóźnieniem, należy otworzyć adres wp-cron.php w przeglądarce. Pusta strona bez błędu to wynik prawidłowy. Błąd, strona logowania albo blokada oznaczają, że dostęp do pliku ogranicza wtyczka zabezpieczająca, zapora lub hasło na katalog i trzeba dodać wyjątek dla tego jednego pliku.
Jakich błędów unikać przy planowaniu zadań?
Większość kłopotów z cron nie wynika z awarii, lecz z decyzji podjętych przy dodawaniu zadania. Te powtarzają się najczęściej.
- Zbyt duża częstotliwość. Zadanie co minutę, które trwa dwie minuty, nakłada się samo na siebie i obciąża konto aż do przekroczenia limitów.
- Kilka ciężkich zadań o tej samej porze. Kopię, import i wysyłkę rozkłada się na różne godziny.
- Wyciszenie zadania przed pierwszym udanym testem. Błędy trafiają wtedy donikąd.
- Powiadomienia kierowane na skrzynkę, której nikt nie czyta, albo na adres byłego wykonawcy.
- Skrypt z hasłami umieszczony w katalogu publicznym, dostępny dla każdego, kto zna adres.
- Zadania, o których nikt nie pamięta. Stare zadanie po zmianie sklepu lub wtyczki potrafi latami wywoływać nieistniejący plik albo, co gorsze, nadpisywać aktualne dane starymi.
Ostatni punkt uważam za najgroźniejszy. Raz na pół roku, a także po każdej większej zmianie na stronie, listę zadań trzeba przejrzeć i przy każdym wierszu odpowiedzieć na pytanie, czemu służy. Zadanie, którego celu nikt nie zna, należy najpierw wyłączyć lub zanotować jego treść, a dopiero po okresie obserwacji usunąć.
Trzeba też wiedzieć, czego cron nie załatwi. Nie zastąpi nadzoru nad wynikiem: kopia tworzona co noc na tym samym serwerze znika razem z nim w razie awarii, a import z uszkodzonego pliku hurtowni wykona się równie sumiennie jak z poprawnego. Automatyzacja zdejmuje z człowieka uruchamianie, nie odpowiedzialność za skutek.
Najczęstsze pytania
Czy zadanie cron działa, gdy komputer właściciela strony jest wyłączony?
Tak. Zadanie wykonuje serwer hostingu, który pracuje bez przerwy. Komputer i przeglądarka są potrzebne tylko do dodania lub zmiany zadania w panelu, a potem nie biorą w niczym udziału.
Jaki jest najkrótszy odstęp między uruchomieniami?
Sama usługa cron pozwala uruchamiać zadanie co minutę, ale o faktycznym limicie decyduje hosting. W OVHcloud na hostingu WWW najkrótszy odstęp to godzina. U innych dostawców limit podaje opis pakietu lub pomoc i warto go sprawdzić przed zaplanowaniem pracy sklepu.
Czy można uruchomić zadanie w ostatnim dniu miesiąca?
Składnia pięciu pól nie ma zapisu „ostatni dzień miesiąca”, a wpisanie liczby 31 pominie krótsze miesiące. Najprostsze rozwiązanie to pierwszy dzień następnego miesiąca tuż po północy. Jeśli potrzebny jest dokładnie ostatni dzień, warunek musi sprawdzać sam skrypt.
Dlaczego zadanie uruchamia się godzinę albo dwie później, niż ustawiono?
Serwer najpewniej pracuje w innej strefie czasowej niż polska, często w czasie uniwersalnym. Trzeba ustalić czas serwera w pomocy hostingu i odpowiednio przesunąć godzinę w harmonogramie, pamiętając, że różnica zmienia się wraz ze zmianą czasu na letni i zimowy.
Czy wyniki zadań muszą przychodzić na pocztę?
Nie muszą. W cPanel usunięcie adresu z części „Cron Email” wyłącza powiadomienia dla wszystkich zadań, a dopisanie na końcu polecenia fragmentu >/dev/null 2>&1 wycisza pojedyncze zadanie. Lepiej jednak zostawić jakikolwiek ślad, choćby własny plik dziennika.
Co się stanie, gdy poprzedni przebieg jeszcze trwa, a przyszła pora na następny?
Cron nie czeka na zakończenie poprzedniego przebiegu i uruchomi kolejny równolegle. Dwa przebiegi tego samego importu mogą zdublować dane, a kilka naraz spowolnić stronę. Odstęp powinien być wyraźnie dłuższy niż czas pracy skryptu.
Czy zadania cron przenoszą się razem ze stroną na nowy hosting?
Nie. Kopia plików i bazy danych nie zawiera listy zadań, bo jest ona częścią ustawień konta na serwerze. Przed migracją trzeba spisać harmonogramy i polecenia, a na nowym serwerze dodać je ponownie, poprawiając ścieżki do katalogu domowego i do PHP.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
Zadania cron wyglądają niewinnie, ale jedna gwiazdka w złym polu potrafi uruchomić skrypt sześćdziesiąt razy zamiast raz, a jedna litera w ścieżce sprawia, że kopia nie powstaje przez wiele miesięcy i nikt o tym nie wie. Rozumiem, że nie każdy ma czas i cierpliwość, żeby to sprawdzać. Mogę zająć się tym w całości: przejrzę panel hostingu i istniejące zadania, ustalę ograniczenia konta, przygotuję polecenia i harmonogramy, dodam je, przetestuję i zostawię krótki opis, co uruchamia się o której porze i gdzie szukać wyników.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i opisać w dwóch zdaniach, co ma się dziać automatycznie. Resztę ustalę w rozmowie.



