Cron job

Cron job to pojedyncze zadanie zaplanowane do cyklicznego wykonywania przez demona cron w systemach uniksowych. W praktyce jest to jeden wiersz w pliku crontab: definicja czasu plus polecenie — skrypt powłoki, program lub wywołanie adresu URL — które system uruchomi automatycznie o wyznaczonych porach.

Na czym polega cron job

Każde zadanie opisuje się harmonogramem złożonym z pięciu pól (minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia) oraz poleceniem do wykonania. Kilka przykładów:

• */5 * * * * php /var/www/app/artisan schedule:run — co 5 minut uruchamia harmonogram aplikacji Laravel,
• 0 4 * * * mysqldump baza | gzip > /backup/baza.sql.gz — codziennie o 4:00 wykonuje zrzut bazy danych,
• 0 0 1 * * /usr/local/bin/raport-miesieczny.sh — pierwszego dnia każdego miesiąca generuje raport.

Zadanie wykonuje się z uprawnieniami użytkownika, w którego crontabie zostało zapisane, oraz w minimalnym środowisku — bez zmiennych sesji interaktywnej. Dlatego w cron jobach zawsze podaje się pełne ścieżki do programów i plików, a wyjście przekierowuje do logu, żeby błędy nie ginęły bez śladu.

Zastosowanie w praktyce

Cron joby to codzienność administracji serwerami i utrzymania aplikacji webowych: kopie zapasowe, rotacja logów, czyszczenie katalogów tymczasowych, synchronizacja danych między systemami, odnawianie certyfikatów, wysyłka newsletterów czy przeliczanie statystyk poza godzinami szczytu. Systemy CMS i frameworki często wymagają własnego cron joba — np. zastąpienie wp-cron w WordPressie prawdziwym zadaniem systemowym odciąża ruch użytkowników, a Laravel opiera na jednym wpisie cały swój scheduler.

Na hostingu współdzielonym zadania dodaje się przez panel administracyjny, na VPS-ie — bezpośrednio w crontabie. Dobre praktyki niezależne od środowiska:

• loguj wynik każdego zadania i ustaw powiadomienia o błędach (choćby przez MAILTO),
• zabezpiecz zadania przed nakładaniem się — jeśli poprzednie wykonanie jeszcze trwa, kolejne powinno się wycofać (np. flock),
• rozkładaj ciężkie zadania poza godziny największego ruchu,
• unikaj harmonogramu „co minutę” tam, gdzie wystarczy rzadziej — każdy job to obciążenie serwera.