Tajniki crona

Każdy administrator strony, nawet ten parający się tym amatorsko, zna pojęcie zadań cron. Dotyczy to głównie osób korzystających z hostingu, a nie administrujących własnymi serwerami. Jak wiadomo owo czteroliterowe słowo oznacza mechanizm uruchomiony na serwerze, umożliwiający na planowe uruchamianie własnych skryptów na serwerze - nawet jeśli nie ma się kontroli nad serwerem (czyli np. ma się wykupiony jedynie hosting). Niby wszystko jest oczywiste i jasne, ale gdy przychodzi potrzeba dodania konkretnego zadania cron, to nierzadko pojawia się problem: albo z prawidłowym zapisem ścieżki do naszego skryptu, albo z właściwym opisaniem reguł częstotliwości jego uruchamiania. Poniżej garść wskazówek w tej materii.
Po pierwsze - reguły częstotliwości. W większości paneli administracyjnych formularz dodawania nowego zadania wygląda mniej więcej tak (tutaj przykład z webd.pl):

(Oczywiście układ pól może być inny, zawsze jednak jest sześć pól, opisujących: minuty, godziny, dni, miesiące, dni tygodnia oraz ścieżkę do polecenia.)
W polach dotyczących czasu i daty możemy wpisywać wartości liczbowe lub znaki specjalne, które umożliwiają wprowadzenie bardziej wyrafinowanych konfiguracji. Najważniejszy znak to *. Jest on równoznaczny ze słowem "każdy(a)". Jeśli zatem postawimy * w polu godziny, oznaczać to będzie uruchamianie skryptu dla każdej godziny. Kolejne znaki specjalne to - oraz , (przecinek). Myślnik pozwala na wprowadzenie przedziałów (np. zapis "12-30" w polu minut oznacza - co minutę pomiędzy 12 a 30 minutą, włącznie), przecinek zaś na podanie listy pojedynczych wartości ("1,4,11" w polu miesięcy to inaczej w styczniu, kwietniu i listopadzie). Kolejny przydatny znak to / (slash, łamana). Jego użycie jest już "wyższą szkołą jazdy". Mianowicie pozwala on na wybór co którejś wartości. Przykładowo zapis "5/11" w polu minut oznacza "w 5 minucie oraz potem co 11 minut (w ramach danej godziny)", czyli ostatecznie w 5, 16, 27, 38 i 49 minucie. (Warto tu podkreślić, że ten odstęp co-ileś-tam np. minut dotyczy tylko konkretnego jednego przedziału czasowego z wyższego rzędu. Czyli np. co 11 minuta, ale w ramach jednej godziny; jeśli zaczynamy nową godzinę, to liczymy to od nowa.) W praktyce najczęściej spotykanym (i wartym do zapamiętania) jest zapis np. "*/3", który oznacza po prostu co trzeci - np. co trzeci dzień.
Niektóre specyfikacje crona przewidują także takie opcje, jak określanie w polu dnia np. ostatniego dnia wtorku miesiąca (zapis "2L" w polu "dzień tygodnia") lub ostatniego dnia w miesiącu (zapis "L" w polu "dzień"). Trzeba mieć na uwadze także to, że o ile w polu "miesiąc" wpisujemy - dosyć intuicyjnie - liczby pomiędzy 1 a 12, to jeśli chodzi o dni tygodnia, metoda liczenia jest inna: 0 to niedziela, 1 wtorek i tak aż do szóstki odpowiadającej sobocie.
Najważniejsze jest to, żeby pamiętać, że zapis reguły jest logiczną koniunkcją warunków we wszystkich polach czasu i daty. Oznacza to, że jeśli wpiszemy w polu "minuta" *, ale w polu "dzień" 1, to nie mamy skryptu uruchamianego co minutę zawsze, lecz jedynie w pierwszy dzień miesiąca co minutę (przez całą dobę, jeśli wpisaliśmy także * w polu "godzina"), a inne dni - wcale. Jest to łatwe do stosowania, ale przy bardziej skomplikowanych regułach można się trochę i zamotać, lepiej więc dwa razy się upewnić, czy nasza reguła ma zamierzony przez nas sens.
Dla lepszego oglądu podaję przykładowe zapisy:
0 17 * * * - codziennie o godzinie 17.00
0 */3 * * 5 - w piątki przez całą dobę co 3 godziny o pełnej godzinie
0 9-17 * * 1-5 - od poniedziałku do piątku co godzinę o pełnej godzinie od 9.00 do 17.00
- i tak dalej.
Odnośnie ostatniego pola w formularzu dodawania nowego zadania - czyli pola ścieżki do skryptu - sprawa jest zależna od konkretnej realizacji na danym serwerze. Niektóre bowiem firmy oferujące hosting wymagają tu podania URL naszego skryptu, inne ścieżki do pliku taka, jak jest na serwerze. Pierwszą metodę stosuje np. wspomniany wyżej webd.pl, drugą natomiast - hekko.pl. (W tym drugim przypadku ścieżka powinna mieć postać: /usr/local/bin/php /home/nazwa_użytkownika/dalsza_ścieżka_do_pliku/plik.php) Ponadto niektóre serwery domagają się podania im przed adresem polecenia wget (to raczej wtedy, gdy podajemy ścieżkę w postaci adresu URL, czyli np. http://moja_domena.pl/moje_skrypty/moj_plik.php).
Domyślnie program obsługujący harmonogram zadań cron (linuksiarze powiedzieliby zamiast program - deamon ;)) wysyła swoje wyjście (czyli wszystko to, co wydrukujemy np. poleceniami echo lub print() w PHP), a także ewentualne komunikaty błędu - na podany mejl administratora hostingu. To może być przydatne w czasie testów, gdy chcemy mieć np. informację "Udało się"/"Nie udało się", w zależności, czy skrypt zadziałał poprawnie, czy nie. Gdy jednak uruchomimy takie zadanie już w normalnej pracy, z dużą częstotliwością, to nasza skrzynka pocztowa zostanie błyskawicznie (jeśli ustawimy zadanie cron np. co minutę...) zasypana potwierdzeniami typu "Udało się wykonać skrypt!". Można oczywiście usunąć wszystkie instrukcje drukujące cokolwiek w naszym cronowym skrypcie, jeśli jednak chcemy mieć pewność, że nic nam nie będzie zasypywać skrzynki, to możemy wybrać opcję, aby program obsługujący harmonogram w ogóle nam nie wysyłał mejli. W panelu administracyjnym na hostingu w hekko.pl realizuje się to poprzez kliknięcie w klawisz "Nie wysyłaj mejli" lub dopisanie w polu polecenia, po ścieżce do skryptu poniższej komendy: >> /dev/null 2>&1

Bibliografia:
http://www.pomoc.hekko.pl/content/5/37/pl/jak-uruchomi%E6-skrypty-php-w-cron-.html
http://markus.revti.com/2008/06/meaning-of-devnull-21-in-crontab%E2%80%99s-cron-job/
http://en.wikipedia.org/wiki/Cron