Cron to systemowy harmonogram zadań w Linuxie, który automatycznie uruchamia komendy lub skrypty o określonym czasie – co minutę, godzinę, dzień, tydzień lub w dowolnym innym interwale. Cron job (zadanie cron) to pojedyncze polecenie zaplanowane w crontab. Przykład: 0 3 * * * /usr/local/bin/backup.sh – uruchamia backup codziennie o 3:00 w nocy. Na serwerze Ubuntu/Debian cron jest preinstalowany i działa w tle (demon crond). Każdy użytkownik systemu ma własny crontab – edytujesz go komendą crontab -e.
Jak działa cron
Demon cron działa w tle od startu systemu. Co minutę sprawdza: czy któryś wpis w crontab pasuje do bieżącej daty i godziny – jeśli tak, uruchamia przypisaną komendę. Crontab to plik tekstowy – każdy wiersz to jedno zadanie z harmonogramem i komendą. Systemowy crontab: /etc/crontab (dla root i zadań systemowych). Crontab użytkownika: crontab -e (każdy user ma swój).
Składnia crontab – 5 pól czasu
Każdy wpis crontab ma format:
# minuta godzina dzień_mc miesiąc dzień_tyg komenda
0 3 * * * /path/to/script.sh| Pole | Zakres | Opis |
|---|---|---|
| Minuta | 0–59 | O której minucie |
| Godzina | 0–23 | O której godzinie |
| Dzień miesiąca | 1–31 | Którego dnia |
| Miesiąc | 1–12 | W którym miesiącu |
| Dzień tygodnia | 0–7 | 0 i 7 = niedziela, 1 = poniedziałek |
Znaki specjalne: * = każda wartość. , = lista (np. 1,15 = 1. i 15. dzień). - = zakres (np. 1-5 = pon–pt). / = co ile (np. */15 = co 15 minut).
Przykłady cron jobs
| Harmonogram | Opis |
|---|---|
* * * * * |
Co minutę |
*/5 * * * * |
Co 5 minut |
0 * * * * |
Co godzinę (o pełnej) |
0 3 * * * |
Codziennie o 3:00 |
0 3 * * 1 |
Co poniedziałek o 3:00 |
0 0 1 * * |
Pierwszego dnia miesiąca o północy |
30 2 * * 1-5 |
Pon–pt o 2:30 |
0 */6 * * * |
Co 6 godzin |
Przydatne narzędzie: crontab.guru – wklejasz wyrażenie cron, a strona tłumaczy je na ludzki język i pokazuje najbliższe uruchomienia.
Jak dodać cron job – krok po kroku
Zaloguj się na serwer przez SSH (ssh user@IP_SERWERA). Otwórz edytor crontab:
crontab -ePrzy pierwszym uruchomieniu: system pyta o edytor – wybierz nano (najprostszy). Dodaj wiersz na końcu pliku:
# Backup bazy danych codziennie o 3:00
0 3 * * * mysqldump -u root mojabaza > /home/user/backup/db-$(date +%Y%m%d).sql 2>&1Zapisz (Ctrl+O → Enter → Ctrl+X w nano). Sprawdź czy się zapisało:
crontab -lWażne: w crontab znak % ma specjalne znaczenie (nowa linia) – musisz go escapować jako %. Dlatego $(date +%Y%m%d) zamiast $(date +%Y%m%d).
Typowe zastosowania cron na serwerze
Automatyczny backup. Codzienny dump bazy MySQL + archiwizacja plików → wysyłka na zewnętrzny storage (S3, Google Drive, FTP). Bez crona: musisz pamiętać o ręcznym backupie – a zapominasz, aż kiedyś stracisz dane.
Aktualizacja systemu. 0 4 * * 0 sudo apt update && sudo apt upgrade -y – automatyczna aktualizacja Ubuntu co niedzielę o 4:00. Alternatywa: unattended-upgrades (bardziej kontrolowane).
Czyszczenie logów i plików tymczasowych. Logi serwera rosną w nieskończoność – cron kasuje stare: 0 5 * * * find /var/log -name "*.log" -mtime +30 -delete (usuń logi starsze niż 30 dni).
Monitoring i alerty. Skrypt sprawdzający co 5 minut: czy strona odpowiada, czy dysk nie jest pełny, czy baza działa – jeśli nie, wysyła email/SMS.
WordPress WP-Cron replacement. WordPress ma własny system zaplanowanych zadań (wp-cron), ale jest odpalany przy każdym odwiedzeniu strony – co na stronach z małym ruchem oznacza, że zadania nie uruchamiają się na czas. Rozwiązanie: wyłącz wp-cron (define('DISABLE_WP_CRON', true); w wp-config.php) i dodaj systemowy cron: */5 * * * * curl -s https://twojadomena.pl/wp-cron.php > /dev/null 2>&1.
Generowanie raportów i emaili. Dzienny raport sprzedaży, tygodniowy newsletter, miesięczna faktura – skrypt generuje i wysyła automatycznie.
Debugowanie cron jobs
Przekieruj output do pliku. Domyślnie cron wysyła output komendy na email użytkownika – ale jeśli email nie jest skonfigurowany, output przepada. Rozwiązanie: 0 3 * * * /path/to/script.sh >> /var/log/myscript.log 2>&1 – output (stdout + stderr) trafia do pliku.
Sprawdź czy cron w ogóle działa: systemctl status cron (Ubuntu) lub systemctl status crond (CentOS). Powinien być „active (running)”.
Sprawdź logi crona: grep CRON /var/log/syslog (Ubuntu) – pokaże kiedy cron uruchomił jakie zadanie.
Pełne ścieżki. Cron nie ładuje Twojego .bashrc – zmienne środowiskowe (PATH) mogą być inne. Zawsze używaj pełnych ścieżek: /usr/bin/php zamiast php, /usr/bin/node zamiast node. Sprawdź ścieżkę: which php.
Uprawnienia. Skrypt musi mieć uprawnienia do wykonania: chmod +x /path/to/script.sh. Cron uruchamia zadanie jako użytkownik, który je dodał – nie jako root (chyba że edytujesz crontab roota: sudo crontab -e).
Cron vs systemd timers
Nowoczesna alternatywa dla crona na Linuxie to systemd timers. Zalety: lepsza obsługa zależności, logowanie (journalctl), możliwość uruchomienia „po starcie systemu” (nie tylko o konkretnej godzinie), monotonic timers (np. „co 30 min od ostatniego uruchomienia”). Wady: bardziej złożona konfiguracja (dwa pliki: .timer + .service zamiast jednego wiersza w crontab). Dla prostych zadań: cron jest wygodniejszy. Dla złożonych, z zależnościami: systemd timers.
Najczęściej zadawane pytania
Jak usunąć cron job?
crontab -e → znajdź wiersz → usuń go (lub zakomentuj dodając # na początku) → zapisz. Usunięcie WSZYSTKICH zadań: crontab -r (uwaga: usuwa cały crontab bez potwierdzenia!). Bezpieczniej: crontab -l > backup-crontab.txt (backup) → potem crontab -r.
Czy cron działa gdy serwer jest wyłączony?
Nie – cron działa tylko gdy system jest uruchomiony. Jeśli serwer był wyłączony o 3:00 i miałeś zadanie zaplanowane na 3:00 – nie uruchomi się po starcie. Nie ma „nadrabiania zaległości”. Alternatywa: anacron – uruchamia zaległe zadania po starcie systemu (przydatne na desktopach, mniej na serwerach, które i tak działają 24/7).
Jak uruchomić cron co 30 sekund?
Cron nie obsługuje interwałów krótszych niż 1 minuta. Obejście: dodaj dwa wpisy z przesunięciem: * * * * * /path/to/script.sh i * * * * * sleep 30 && /path/to/script.sh. Lepsze rozwiązanie dla tak częstych zadań: użyj systemd timer z OnUnitActiveSec=30s lub uruchom skrypt jako daemon z pętlą.
Czy cron na hostingu współdzielonym działa tak samo?
Na hostingu współdzielonym (cPanel, DirectAdmin): cron jest dostępny, ale przez panel webowy – klikasz „Cron Jobs” → podajesz harmonogram i komendę. Ograniczenia: minimalna częstotliwość (np. max co 15 minut), limit zasobów CPU, brak dostępu do systemowego crona. Na VPS/Ubuntu: pełna kontrola przez crontab -e.
