Generator CRON

Generator CRON – twórz poprawne harmonogramy zadań w kilka sekund

Generator CRON składa pięć pól harmonogramu w poprawne wyrażenie, dopina polecenie w gotową linię do crontaba i od razu pokazuje, ile razy na dobę zadanie się uruchomi. Przykład: 0 2 * * * to „Codziennie o 02:00”, czyli jedno uruchomienie na dobę. CRON jest prosty, dopóki nie pomylisz pól, zakresów albo nie trafisz na klasyczne „dlaczego to się nie uruchamia?”.

Jeśli chcesz ustawić backupy, raporty, odświeżanie cache, polecenia CLI w aplikacji (np. artisan schedule:run), ping do API albo zwykłe „uruchom to codziennie o 02:00”, jesteś w dobrym miejscu. Wybierasz szablon harmonogramu, podajesz godzinę i minutę (albo przechodzisz na „Własny”), dodajesz polecenie i od razu masz wynik do wklejenia. Wynik przelicza się na bieżąco, bez osobnego przycisku generowania.

Oprócz samego wyrażenia dostajesz opis po polsku (żeby nie zgadywać po samym 0 2 * * 1, że to „W poniedziałki, o 02:00”), tabelę z rozbiciem każdego pola, liczbę uruchomień na dobę, najkrótszy odstęp między nimi i ocenę obciążenia. Obciążenie zmienia się na „Wysokie”, gdy zadanie startuje częściej niż co 5 minut: „co minutę” bywa dobre do testów, ale w produkcji potrafi niepotrzebnie obciążać serwer.

Jak działa CRON w praktyce

CRON to mechanizm planowania zadań w systemach Linux/Unix. Wpisujesz harmonogram w pięciu polach (minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia), a system uruchamia polecenie zgodnie z tym planem. Problem polega na tym, że te pola mają swoje zasady, zakresy i miny – szczególnie wtedy, gdy chcesz coś uruchamiać „co X”, „tylko w dni robocze” albo w konkretnych godzinach.

Zamiast walczyć z pamięciówką, wybierasz szablon (Każda minuta, Co godzinę, Codziennie, Co tydzień, Co miesiąc), klikasz jeden z ośmiu gotowych harmonogramów (np. co 15 minut, dni robocze o 8:00, 1. dnia miesiąca o północy) albo ustawiasz własne wyrażenie. W efekcie masz gotowe wyrażenie CRON, pełną linię wpisu z poleceniem i opis, który mówi wprost, co się wydarzy.

Krok po kroku: wygeneruj wpis do crontaba

Najprostszy scenariusz wygląda tak: wybierasz szablon, uzupełniasz wymagane pola i dodajesz polecenie (opcjonalnie). Wynik dostajesz w dwóch formach: krótkie wyrażenie (same pola CRON) oraz pełną linię do wklejenia do crontaba.

1. Wybierz szablon albo „Własny”. Możesz też kliknąć gotowy harmonogram lub wkleić istniejące wyrażenie.
2. Uzupełnij minutę i godzinę oraz dzień tygodnia lub miesiąca, jeśli szablon o to prosi. Błędne pole zostanie oznaczone z podpowiedzią dozwolonego zakresu.
3. Wpisz polecenie (np. skrypt, polecenie CLI, zadanie w aplikacji). Dla /etc/crontab i /etc/cron.d/ podaj też użytkownika, a jeśli wyjście nie jest potrzebne, zaznacz „Wycisz”.
4. Skopiuj „Wpis do crontab” i wklej go w edytorze otwartym poleceniem crontab -e.

Dla przykładu wczytanego przyciskiem „Wczytaj przykład” wpis wygląda tak: */15 9-17 * * 1-5 php /home/user/app/artisan schedule:run >/dev/null 2>&1. Jeśli pole polecenia zostawisz puste, dostajesz tylko „gołe” wyrażenie z przyciskiem „Kopiuj wyrażenie” – przydaje się do dokumentacji, panelu hostingu albo konfiguracji innego narzędzia.

Mini ściąga: co oznaczają pola CRON

Kolejność pól jest stała. Tabela ratuje przed klasyczną zamianą miesiąca z dniem tygodnia oraz przed wpisaniem 60 w minutach albo 24 w godzinach – generator odrzuci obie wartości.

Generator przyjmuje w polach tylko liczby i znaki * , - /. Nazw w rodzaju MON czy JAN ani siódemki jako niedzieli nie wpiszesz – dla niedzieli użyj 0.

Przykłady wyrażeń cron, które naprawdę się przydają

CRON najlepiej zrozumieć na przykładach. Poniżej ustawienia, które regularnie pojawiają się w realnych projektach, z opisem i liczbą uruchomień, jakie pokaże generator.

Te pułapki łapią nawet doświadczonych

Najczęstsza: wpisujesz dzień miesiąca i dzień tygodnia jednocześnie, a zadanie uruchamia się częściej, niż oczekujesz. W klasycznym crondzie te pola działają w trybie „albo/albo”, a nie „i”: 0 8 1 * 1 generator opisze jako „1. dnia miesiąca lub w poniedziałki, o 08:00” i doda ostrzeżenie. Jeśli nie musisz, trzymaj jedno z tych pól jako *.

Druga: krok, który nie dzieli zakresu równo. */7 w minutach daje starty o :00, :07 … :56, a potem znowu o :00 następnej godziny, więc ostatni odstęp to 4 minuty, nie 7. Generator policzy wtedy 216 uruchomień na dobę, pokaże najkrótszy odstęp 4 min i ostrzeże o nierównych odstępach. Podobnie zakres godzin jest włącznie z końcem: */15 9-17 ostatni raz uruchomi zadanie o 17:45, a nie o 17:00.

Trzecia: strefa czasowa. Serwer może działać w innym czasie niż Ty. Jeśli ustawiasz zadanie „o 2:00”, a serwer jest w UTC, to zadanie działa, tylko o innej godzinie. W nocy zmiany czasu (okolice 2:00–3:00) zadanie może się nie wykonać albo wykonać dwa razy. Generator pilnuje składni, ale kontekst (serwer, kontener, użytkownik) nadal jest po Twojej stronie. Dni 29–31 też mają haczyk: w krótszych miesiącach zadanie się nie uruchomi, o czym generator przypomni.

Obciążenie i bezpieczeństwo: małe rzeczy, które robią dużą różnicę

Ustawienie harmonogramu to jedno, ale utrzymanie go w ryzach to drugie. Jeśli uruchamiasz zadanie często, a ono generuje dużo wyjścia (stdout/stderr), cron potrafi zasypać Cię mailami systemowymi albo zajmować zasoby. Dlatego warto mieć nawyk przekierowania logów oraz świadomego dobierania częstotliwości.

Opcja „Wycisz” dopisuje do polecenia >/dev/null 2>&1, czyli odrzuca całe wyjście razem z błędami. Jeśli wynik ma znaczenie, zostaw ją wyłączoną i dopisz w poleceniu przekierowanie do pliku, np. >> /var/log/backup.log 2>&1. To daje ślad: co się uruchomiło, kiedy i z jakim efektem. Pamiętaj też o znaku %: w crontabie oznacza nowy wiersz, więc w poleceniu zapisz go jako \% (np. date +\%Y) – generator ostrzeże, jeśli go wykryje.

• Upewnij się, że polecenie działa ręcznie w terminalu (ten sam użytkownik).
• Sprawdź, czy ścieżki do plików są absolutne (cron nie wie, w jakim katalogu jesteś).
• Dodaj logowanie wyjścia (stdout i stderr), jeśli wynik ma znaczenie.
• Przy częstych uruchomieniach unikaj nakładania się procesów (flock, timeout).
• Zweryfikuj strefę czasową serwera poleceniem date, jeśli godziny się nie zgadzają.
• Nie ustawiaj „co minutę” dla ciężkich zadań, jeśli nie musisz.