Crontab i 5 przykładów, które zautomatyzują Twoje zadania

Crontab to niezbędne narzędzie w systemach Linux, służące do automatycznego wykonywania powtarzalnych zadań. Jego działanie opiera się na harmonogramie zdefiniowanym za pomocą pięciu pól czasowych, co pozwala uruchomić dowolny skrypt lub polecenie z dokładnością co do minuty. Dzięki niemu zautomatyzujesz tworzenie kopii zapasowych czy generowanie raportów, oszczędzając czas i ograniczając ryzyko ludzkiego błędu.

Co to jest crontab i do czego służy?

Crontab to plik konfiguracyjny oraz polecenie w systemach uniksopodobnych (Linux, Unix), które służy do zarządzania harmonogramem zadań. Stanowi tabelę instrukcji dla demona cron – procesu systemowego działającego w tle, który cyklicznie sprawdza zawartość pliku i uruchamia zapisane w nim skrypty lub polecenia o precyzyjnie określonym czasie. Dzięki temu crontab jest podstawowym narzędziem do automatyzacji.

Głównym zadaniem crontab jest odciążenie administratorów i deweloperów od ręcznego wykonywania powtarzalnych czynności. Zamiast pamiętać o codziennym backupie czy cotygodniowym raporcie, zadania te definiuje się raz, a system wykonuje je automatycznie. Do najczęstszych zastosowań należą:

• regularne tworzenie kopii zapasowych baz danych i plików,
• cykliczne czyszczenie logów systemowych lub katalogów tymczasowych,
• uruchamianie skryptów generujących okresowe raporty (np. finansowe, statystyk ruchu),
• synchronizacja lub aktualizacja danych w określonych odstępach czasu.

Crontab wywodzi się z wczesnych wersji systemu Unix, a jego najpopularniejsza implementacja w dystrybucjach Linuksa to vixie-cron. Stabilność i prostota sprawiają, że od dekad pozostaje standardem w automatyzacji zadań serwerowych.

Składnia crontab: jak poprawnie tworzyć zadania?

Poprawne tworzenie zadań w crontab wymaga ścisłego przestrzegania składni, która definiuje czas wykonania polecenia. Demon cron analizuje każdy wpis jako sekwencję pięciu pól czasowych, po których następuje polecenie do uruchomienia. Zachowanie kolejności i wartości w tych polach jest kluczowe do prawidłowego działania zadań.

Struktura zadania to:
minuta godzina dzień_miesiąca miesiąc dzień_tygodnia /ścieżka/do/polecenia

Pola czasowe przyjmują następujące wartości:

• minuta – od 0 do 59,
• godzina – od 0 do 23,
• dzień miesiąca – od 1 do 31,
• miesiąc – od 1 do 12 lub trzyliterowa angielska nazwa (np. Jan, Feb),
• dzień tygodnia – od 0 do 7, gdzie 0 i 7 oznaczają niedzielę.

Pola oddziela się spacjami. Jeśli pole ma przyjmować dowolną wartość, stosuje się gwiazdkę (*). Na przykład:
* * * * * /usr/bin/script.sh oznacza uruchamianie skryptu co minutę, każdego dnia.

Budowa wpisu: 5 pól czasowych i komenda

Każda linia w pliku crontab ma stałą strukturę: pięć pól definiujących moment wykonania oraz polecenie do uruchomienia. Ta kolejność jest niezbędna do poprawnej interpretacji przez demona cron. Pola czasowe oddziela się spacjami.

Szczegóły pól:

• minuta – 0–59,
• godzina – 0–23,
• dzień miesiąca – 1–31,
• miesiąc – 1–12 lub skrócona nazwa angielska,
• dzień tygodnia – 0–7, gdzie 0 i 7 to niedziela.

Po tych pięciu polach następuje polecenie powłoki lub ścieżka do skryptu, które zostaną wykonane w ustalonym terminie.

Operatory specjalne do precyzyjnego harmonogramu

Crontab wykorzystuje dodatkowe operatory, które rozszerzają możliwości definiowania harmonogramów. Poza gwiazdką (*) znaczące są:

• Operator zakresu (-): Definiuje ciągły zakres wartości. Na przykład 8-11 w polu godziny uruchomi zadanie o godzinach 8, 9, 10 i 11.
• Operator listy (,): Pozwala wyliczyć konkretne, nieciągłe wartości. Zapis 1,15 w dniu miesiąca uruchomi zadanie pierwszego i piętnastego dnia.
• Operator kroku (/): Określa częstotliwość wykonania w zakresie. */10 w minutach oznacza uruchomienie co 10 minut, a */2 w godzinach – co dwie godziny.

Skróty czasowe: @reboot, @daily, @hourly

Crontab oferuje skróty, które zastępują standardowe pięć pól czasowych, upraszczając definicję popularnych harmonogramów:

• @reboot – uruchamia polecenie raz po restarcie systemu, przydatne do inicjalizacji usług poza systemowym menedżerem startu.
• @hourly – wykonuje zadanie na początku każdej godziny (0 * * * *).
• @daily / @midnight – uruchamia codziennie o północy (0 0 * * *).
• @weekly – raz w tygodniu w niedzielę o północy (0 0 * * 0).
• @monthly i @yearly (również @annually) – odpowiednio pierwszego dnia miesiąca (0 0 1 * *) oraz pierwszego stycznia (0 0 1 1 *).

Zmienne środowiskowe: PATH, SHELL, MAILTO

Zadania crona wykonują się w ograniczonym i izolowanym środowisku. Dlatego na początku pliku crontab można ustawić zmienne środowiskowe, które zapewnią poprawne działanie poleceń i obsługę powiadomień:

• SHELL – określa powłokę systemową wykonującą polecenia. Domyślnie /bin/sh, ale np. SHELL=/bin/bash pozwala korzystać ze specyficznych funkcji Basza.
• PATH – definiuje ścieżkę do katalogów z plikami wykonywalnymi. Bez niej cron może nie znaleźć poleceń. Przykład ustawienia: PATH=/sbin:/bin:/usr/sbin:/usr/bin.
• MAILTO – adres e-mail, na który są wysyłane wyniki działania zadania. Jeśli ustawione na pusty ciąg (MAILTO=""), powiadomienia nie będą wysyłane.

Jak zarządzać zadaniami? Polecenia crontab

Zarządzanie zadaniami odbywa się wyłącznie przez polecenie crontab z odpowiednimi opcjami. Nie ma potrzeby bezpośredniej edycji plików systemowych w katalogu /var/spool/cron/crontabs/.

Podstawowe komendy to:

• crontab -e – otwiera edytor (np. nano lub vim) do edycji pliku zadań dla bieżącego użytkownika. Po zapisaniu zmiany są automatycznie stosowane.
• crontab -l – wyświetla aktualną listę zaplanowanych zadań.
• crontab -r – usuwa cały plik crontab bieżącego użytkownika, operacja jest nieodwracalna i wymaga ostrożności.

Aby edytować zadania innego użytkownika, stosuje się:
sudo crontab -e -u nazwa_uzytkownika

Po zmianach demon cron automatycznie wczytuje nową konfigurację, nie wymaga to restartu usługi.

Gotowe przykłady crontab: od prostych do złożonych

Poznanie działania crontab najlepiej zacząć od praktycznych przykładów, które pokazują różne poziomy złożoności harmonogramów. W przykładach echo ... służy do demonstracji – w praktyce zastępuje się je rzeczywistymi skryptami.

• Uruchamianie zadania co godzinę:
  0 * * * * /sciezka/do/skryptu.sh
  Zadanie wykona się na początku każdej godziny (np. 8:00, 9:00).

• Codzienny backup o 2:30 w nocy:
  30 2 * * * /usr/bin/backup.sh
  Skrypt uruchomi się codziennie o 2:30, gdy obciążenie jest najmniejsze.

• Cotygodniowy raport w niedzielę o północy:
  0 0 * * 0 /bin/generuj_raport.sh
  Wykonywany raz w tygodniu niedzielę o 00:00, często do raportów lub konserwacji.

• Cykliczne monitorowanie w godzinach pracy:
  */10 8-17 * * 1-5 /opt/monitoring.sh
  Skrypt uruchamiany co 10 minut od poniedziałku do piątku między 8:00 a 17:59.

• Złożony warunek: piątki oraz 1 i 15 dnia miesiąca:
  30 4 1,15 * 5 /sciezka/do/komendy
  Zadanie uruchomi się o 4:30, jeśli jest piątek LUB dzień miesiąca to 1 lub 15. Warunki dnia tygodnia i dnia miesiąca działają jak logiczne „LUB”.

Jak debugować zadania crona i unikać błędów?

Najczęstszym problemem jest ciche niepowodzenie zadania – skrypt nie działa, a administrator pozostaje bez informacji zwrotnej. Podstawową metodą debugowania jest przekierowanie zarówno standardowego wyjścia, jak i błędów do pliku logu, np.:

>> /sciezka/do/pliku.log 2>&1  

Dzięki temu wszystkie komunikaty trafiają do wskazanego pliku, ułatwiając diagnostykę.

Aby zmniejszyć ryzyko błędów, warto stosować kilka dobrych praktyk:

• Używaj pełnych ścieżek do poleceń – środowisko crona ma ograniczoną zmienną PATH. Zamiast skrypt.sh lepiej użyć pełnej ścieżki, np. /home/user/skrypty/skrypt.sh.
• Testuj skrypt ręcznie jako użytkownik, pod którym działa zadanie, aby zweryfikować uprawnienia i działanie.
• Ustawiaj zmienną MAILTO – MAILTO=adres@email.com pozwala otrzymywać wyniki działania każdego zadania mailowo.

Dodatkowo warto sprawdzać logi systemowe, np. w /var/log/syslog lub za pomocą polecenia:

journalctl -u cron

W razie problemów z uruchomieniem zadań sprawdź, czy demon cron jest aktywny poleceniem:

systemctl status cron

Czym zastąpić crona? Alternatywne rozwiązania

Mimo, że cron jest standardem, istnieją alternatywy oferujące inne możliwości automatyzacji:

• systemd timers – nowoczesne narzędzie zintegrowane z menedżerem usług systemd. Pozwala uruchamiać zadania zależnie od stanu systemu (np. po nawiązaniu połączenia sieciowego), zapewnia większą precyzję i integrację z logami journalctl. Konfiguracja wymaga dwóch plików: .timer (harmonogram) i .service (zadanie).
• anacron – przeznaczony dla systemów niepracujących 24/7, takich jak laptopy. Po uruchomieniu systemu sprawdza, czy pominięto wykonanie zadań zgodnie z harmonogramem (np. dziennych) i je nadrabia.
• polecenie at – umożliwia jednorazowe wykonanie polecenia o określonej godzinie w przyszłości. Idealne do pojedynczych zadań, np. at 23:00 tomorrow.

Każde z tych narzędzi ma konkretne zastosowania i może w określonych sytuacjach skuteczniej zastąpić crona.