Co to jest crontab?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: Crontab to tabela z harmonogramem poleceń uruchamianych automatycznie przez usługę cron, najczęściej na systemach Linux i Unix. Nazwa oznacza też polecenie służące do zarządzania tą tabelą. Dzięki crontabowi możesz na przykład codziennie wykonywać kopię zapasową albo co kilka minut uruchamiać skrypt, bez ręcznego logowania na serwer.
Czym różnią się cron i crontab?
Cron to działająca w tle usługa, która sprawdza harmonogram i uruchamia zapisane polecenia o określonych porach. Crontab jest konfiguracją tego harmonogramu. Sam wpis nie wystarczy: usługa cron musi być zainstalowana i uruchomiona, a komputer lub serwer musi działać w zaplanowanym czasie.
Użytkownicy mogą mieć własne tabele crontab. Zadanie wykonuje się z uprawnieniami właściciela danej tabeli, więc wpis dodany przez zwykłego użytkownika nie otrzymuje automatycznie dostępu administratora. Ma to znaczenie zarówno dla bezpieczeństwa, jak i dostępu do plików.
Cron sprawdza się przy regularnych zadaniach technicznych: generowaniu raportów, synchronizacji danych czy usuwaniu plików tymczasowych. Nie reaguje jednak sam z siebie na zdarzenia, takie jak złożenie zamówienia — uruchamia polecenia zgodnie z czasem zapisanym w konfiguracji.
Jak czytać wpis w crontabie?
W crontabie użytkownika każdy wpis zawiera pięć pól czasu, a po nich polecenie:
minuta godzina dzień_miesiąca miesiąc dzień_tygodnia polecenie
Pola są oddzielone spacjami lub tabulatorami. Ich podstawowe znaczenie przedstawia tabela:
| Pole | Typowy zakres | Znaczenie gwiazdki * |
|---|---|---|
| Minuta | 0–59 | Każda minuta |
| Godzina | 0–23 | Każda godzina |
| Dzień miesiąca | 1–31 | Każdy dzień miesiąca |
| Miesiąc | 1–12 | Każdy miesiąc |
| Dzień tygodnia | 0–7, zwykle 0 i 7 to niedziela | Każdy dzień tygodnia |
Przykładowy wpis:
30 2 * * * /home/anna/bin/backup.sh
Oznacza uruchomienie skryptu backup.sh codziennie o 02:30. Godzina jest interpretowana według strefy czasowej używanej przez cron, najczęściej ustawionej na serwerze, a nie na komputerze osoby edytującej harmonogram.
Przy zapisie terminów przydają się również przecinki, zakresy i kroki:
0 8 * * 1-5— o 08:00 od poniedziałku do piątku.0 9,17 * * *— codziennie o 09:00 i 17:00.*/15 * * * *— w minutach 0, 15, 30 i 45 każdej godziny.
Krok nie oznacza odstępu liczonego od zakończenia zadania. Wpis */15 uruchamia polecenie według zegara, nawet jeśli poprzednie wykonanie jeszcze trwa. Z kolei */7 w polu minut nie daje równych siedmiominutowych odstępów przez całą dobę: po minucie 56 następuje minuta 0 kolejnej godziny.
Istotna pułapka dotyczy pól dnia miesiąca i dnia tygodnia. W popularnych implementacjach, gdy oba są ograniczone, wystarczy spełnienie jednego z tych warunków. Wpis 0 9 1 * 1 oznacza więc godzinę 09:00 pierwszego dnia miesiąca lub w poniedziałek, nie wyłącznie w poniedziałek przypadający pierwszego dnia miesiąca. Szczegóły składni sprawdzisz w dokumentacji swojej implementacji, zwykle przez man 5 crontab.
Jak dodać i sprawdzić zadanie?
Najbezpieczniej zacząć od nieszkodliwego testu, który zapisuje datę do pliku. Pozwala to sprawdzić harmonogram niezależnie od działania właściwego skryptu.
- Otwórz tabelę bieżącego użytkownika poleceniem
crontab -e. - Dodaj poniższy wpis, dostosowując ścieżki do swojego systemu.
- Zapisz plik i zamknij edytor.
- Po upływie jednej–dwóch minut sprawdź plik wynikowy.
* * * * * /usr/bin/date >> /home/anna/cron-test.log 2>&1
Operator >> dopisuje wynik do pliku zamiast go nadpisywać. Zapis 2>&1 kieruje komunikaty błędów w to samo miejsce. Katalog docelowy musi istnieć, a użytkownik musi mieć prawo zapisu.
Polecenie crontab -l wyświetla zapisane zadania. Po udanym teście usuń testowy wiersz przez crontab -e i dodaj właściwy harmonogram. Uważaj na crontab -r: usuwa całą tabelę użytkownika, nie pojedynczy wpis.
Nie myl tabeli użytkownika z systemowym plikiem /etc/crontab. W tym pliku oraz typowych plikach w /etc/cron.d/ pomiędzy polami czasu a poleceniem występuje dodatkowe pole z nazwą użytkownika wykonującego zadanie.
Dlaczego skrypt działa ręcznie, ale nie przez cron?
Cron uruchamia polecenia w innym, zwykle skromniejszym środowisku niż terminal użytkownika. Nie należy zakładać, że wczyta konfigurację powłoki, zna te same zmienne lub rozpocznie pracę w katalogu skryptu.
Przy diagnozie sprawdź przede wszystkim:
- Ścieżki: używaj pełnych ścieżek do programów i plików; jeśli skrypt potrzebuje konkretnego katalogu, ustaw go jawnie.
- Uprawnienia: użytkownik zadania musi móc odczytać dane i zapisać wynik; bezpośrednio uruchamiany skrypt potrzebuje prawa wykonywania oraz poprawnej linii wskazującej interpreter.
- Środowisko: ustaw wymagane zmienne i właściwy interpreter zamiast polegać na konfiguracji terminala.
- Logi: zapisuj wynik i błędy zadania; sprawdź też status usługi oraz dzienniki crona właściwe dla systemu.
Jeżeli zadanie może trwać dłużej niż odstęp między uruchomieniami, zastosuj blokadę zapobiegającą równoległym wykonaniom, na przykład narzędziem flock, jeśli jest dostępne. Sam cron nie zapewnia takiej ochrony.
Kiedy potrzebujesz czegoś więcej niż crontab?
Klasyczny cron zwykle nie nadrabia zadań pominiętych podczas wyłączenia komputera. Zmiana czasu może też wpływać na wykonania w godzinach przejścia; dokładne zachowanie zależy od implementacji. Dla laptopa lub zadań wymagających nadrabiania zaległości rozważ anacron albo odpowiednio skonfigurowany timer systemd.
Przed dodaniem ważnego zadania uruchom jego polecenie ręcznie jako docelowy użytkownik, a następnie sprawdź wykonanie przez cron z zapisem błędów. Przy kopiach zapasowych sprawdź również możliwość odtworzenia danych — poprawne uruchomienie skryptu nie dowodzi jeszcze, że kopia jest użyteczna.
Zobacz też: Co to jest 2FA?
Przeczytaj także
