Cron vs timery systemd: co wybrać?

Na współczesnej dystrybucji używaj timera systemd do wszystkiego, co jest twoje, a zostaw crona do jednolinijkowych zadań użytkownika i serwerów, których sam nie stawiałeś. Timery logują każde uruchomienie do journala, potrafią nadrabić harmonogram przegapiony, gdy maszyna była wyłączona, i zależą od tych samych plików unit, co wszystko inne w systemie. Cron wygrywa zwięzłością — jedna linijka crontab -e bije dwa pliki unit — i wciąż jest jedynym schedulerem, który na pewno istnieje w minimalistycznych kontenerach i dziwackich maszynach Uniksowych. Haczyk: cron zawodzi po cichu. Jeśli twoje zadanie wywali się o 3 w nocy, cron pisze maila na lokalną skrzynkę, której nikt nie czyta, podczas gdy timer daje ci journalctl -u mytimer.service z pełnym wyjściem. Niżej: prawdziwe różnice, jak przetestować oba, czemu timer może nie strzelić i tabela decyzyjna.

Jaka jest różnica między cronem a timerem systemd?

Cron to demon, który czyta tabelę linii — pięć pól czasu i komenda — i uruchamia komendę, gdy zegar ścienny się zgadza. To cały model. Nie ma pojęcia zadania jako obiektu: ani unitu, ani statusu, ani zależności, ani własnego wpisu w logu.

Timer systemd to plik unit (foo.timer), który odpala inny plik unit (foo.service), gdy pasuje jego harmonogram. Zadanie jest obiektem pierwszej kategorii, z start, status, logami i śledzeniem awarii jak każda inna usługa. Harmonogram jest albo kalendarzowy (cronopodobny), albo monotoniczny (OnBootSec=15min, którego zmiany zegara ściennego nie zmylą).

Praktyczne konsekwencje:

• Logowanie: timery piszą stdout/stderr do journala per unit; cron najwyżej wysyła maila do lokalnego użytkownika.
• Przegapione uruchomienia: timer z Persistent=true odpali się raz przy bootcie, jeśli termin przepadł; cron po prostu pomija.
• Zależności: timery potrafią czekać na network-online.target czy punkty montowania; cron każe ci ręcznie klepać retry w skrypcie.
• Składnia: cron to jedna linia; timer to dwa pliki. To cały koszt przesiadki.

Która składnia jest łatwiejsza — crontab czy OnCalendar?

Pięć pól crona to zwarty obywatel starej daty: */15 * * * * znaczy co 15 minut, a większość adminów czyta te zapisy pół śpiąc. OnCalendar= systemd jest gadatliwszy, ale wyraźnie bardziej ekspresywny, a systemd-analyze calendar powie ci następne uruchomienia, zanim cokolwiek zapiszesz — cron nie ma odpowiednika dry-runa.

# cron: codziennie o 03:30
30 3 * * * /usr/local/bin/backup.sh

# systemd: ten sam harmonogram, do zweryfikowania przed zapisem
systemd-analyze calendar "*-*-* 03:30:00"
# -> następne uruchomienie: Fri 2026-09-11 03:30:00 ...

OnCalendar ogarnia rzeczy, których cron nie umie wyrazić zgrabnie: Mon..Fri *-*-* 09..17:00:00 (dni robocze, godziny biurowe) albo *:0/15 z RandomizedDelaySec=10m, żeby tysiąc maszyn nie biło jednego serwera w tej samej sekundzie.

Jak przetestować timer systemd bez czekania?

Trzy komendy odpowiadają na wszystko. Wypisz, co jest zaplanowane i kiedy strzeli następny raz, odpal zadanie ręcznie dokładnie tak, jak zrobiłby to timer, a potem przeczytaj jego logi:

systemctl list-timers --all                 # każdy timer, następne + ostatnie uruchomienie
sudo systemctl start backup.service         # odpal zadanie teraz, ten sam unit co timer
journalctl -u backup.service -f             # patrz na jego wyjście na żywo

Zauważ podział: systemctl start backup.timer uzbraja harmonogram; usługa jest zadaniem. Jeśli list-timers pokazuje twój timer, systemctl status backup.service świeci na zielono, a journal pokazuje twoje wyjście — cały łańcuch działa.

Jak odpalić zadanie crona ręcznie?

Zadania crona chodzą z wyciętym środowiskiem, dlatego „u mnie w shellu działa, w cronie nie” to osobny gatunek buga. Żeby wiernie odtworzyć crona, odpal komendę przez sh w takim środowisku, jakie cron by użył:

crontab -l                                  # potwierdź dokładną linię
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # czy cron w ogóle go odpalił? (Debian/Ubuntu)
journalctl -u cron -n 20                    # to samo, na dystrybucjach z systemd

Linia z env -i to uczciwy test ręczny: gołe środowisko z domyślnym PATH crona. Większość cichych awarii crona to goły PATH albo nieescapowany % w komendzie (cron traktuje % jako znak nowej linii) — i oba wychodzą od razu.

Czemu mój timer systemd się nie uruchamia?

Cztery przyczyny pokrywają prawie każdy przypadek, w kolejności sprawdzania:

1. Nazwy usługi i timera się nie zgadzają. foo.timer odpala foo.service — literówka w OnFailure albo przemianowany unit oznacza, że timer „uruchamia się” w próżnię. systemctl cat foo.timer pokaże dokładnie, w co celuje.
2. Timer był edytowany, ale nie przeładowany. Po zmianie pliku unit: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. Bez tego twój nowy harmonogram nie żyje.
3. Persistent=true bez semantyki OnCalendar, jakiej oczekujesz — albo sprawdzasz systemctl status foo.timer (zawsze pokazuje active, nawet gdy śpi) zamiast list-timers.
4. Usługa, którą odpala, pada natychmiast, więc timer wygląda na martwy. journalctl -u foo.service --since -1h pokaże crash, którego list-timers nie ujawnia.

A kiedy już zaglądasz w logi, ściąga journalctl pokrywa filtry (-u, --since, -f), które robią to szybko.

Cron vs timery systemd: tabela decyzyjna

	cron	timer systemd
Konfiguracja	jedna linia crontab	dwa pliki unit
Logowanie	lokalny mail, zwykle nieczytany	journal, per unit
Przegapione uruchomienie (maszyna off)	pominięte	wykona się raz z Persistent=true
Zależności / kolejność	brak — DIY w skrypcie	pełne zależności unitów
Losowe opóźnienie	DIY z $RANDOM	RandomizedDelaySec=
Test / dry-run harmonogramu	nie	systemd-analyze calendar
Istnieje wszędzie	tak — kontenery, BSD-y, embedded	wymaga systemd (PID 1)
Zadania użytkownika bez roota	crontab -e	unity systemd --user

Zasady kciuka: zadanie na własnej maszynie z systemd → timer. Szybkie prywatne przypomnienie albo maszyna, której nie stawiałeś → cron. Cokolwiek z zależnościami, retry albo potrzebą wiedzy, czy w ogóle się wykonało → timer, zawsze. Typowy wzorzec to timer odpalający zadanie serwisowe — na przykład nocny backup rsync — gdzie Persistent=true gwarantuje, że backup się zdarzy, nawet jeśli maszyna spała w umówionej minucie. Cron tego po prostu nie umie.