Pora na czasomierz - Porównanie cron i systemd dla automatyzacji zadań

Automatyzacja jest kamieniem węgielnym nowoczesnej administracji Linuksem (i nie tylko), znacznie zwiększając wydajność wykonywania powtarzalnych zadań. W przeszłości leciwe, lecz niezawodne narzędzie cron było podstawowym narzędziem do automatyzacji powtarzających się zadań. W ostatnich latach pojawiła się jednak nowocześniejsza alternatywa dla klasycznego crona: czasomierze bądź timery systemd. Choć systemd init [1] istnieje już od 2010 roku, wielu użytkownikom Linuksa ustawianie timerów poprzez systemd wciąż wydaje się czymś egzotycznym. Duża część użytkowników Linuksa nigdy tak naprawdę nie miała problemu z cronem i nigdy nie widziała powodu, by się przestawić na timery systemd. Mimo to systemd oferuje zaawansowane funkcje, które nie są dostępne w cronie, a jeśli poświęcimy chwilę na naukę, timery systemd przestaną się wydawać skomplikowane. Zdecydowaliśmy, że nadszedł czas, aby porównać te dwie potężne techniki automatyzacji. Zaczniemy od krótkich opisów, następnie porównamy niektóre z istotnych funkcji, a na koniec przyjrzymy się kilku praktycznym przykładom. Jeśli potrzebujesz dodatkowych informacji, zapoznaj się z samouczkiem cron w dalszej części tego wydania.

Cron do automatyzacji zadań

Cron, pochodzący od greckiego słowa „chronos” oznaczającego czas, jest opartym na czasie mechanizmem ustalania harmonogramów zadań w uniksowych systemach operacyjnych [2]. Cron pozwala użytkownikom zaplanować polecenia lub skrypty, znane jako zadania cron, do okresowego uruchamiania w ustalonych godzinach, datach lub odstępach czasu. Zachowanie crona jest regulowane przez pliki crontab (skrót od „cron table”). Plik crontab jest plikiem konfiguracyjnym określającym harmonogram i polecenie, które ma zostać wykonane [3]. Użytkownicy mogą tworzyć własne pliki crontab i zazwyczaj istnieje ogólnosystemowy plik crontab dla zadań administracyjnych.

Podstawową jednostką crona jest zadanie cron, które jest definiowane przez określoną składnię w pliku crontab. Każda linia w crontab reprezentuje zadanie i składa się z wyrażenia cron, po którym następuje polecenie do wykonania. Standardowe wyrażenie cron składa się z pięciu pól reprezentujących minutę (0-59), godzinę (0-23), dzień miesiąca (1-31), miesiąc (1-12 lub JAN-DEC) i dzień tygodnia (0-6 lub SUN-SAT). Pola te są oddzielone spacjami, a każde z nich może zawierać określone wartości, zakresy, listy lub gwiazdkę (*) oznaczającą wszystkie możliwe wartości w danym polu. Na przykład * * * * * /ścieżka/do/polecenia będzie wykonywać określone polecenie co minutę.

Znaki specjalne dodatkowo zwiększają elastyczność wyrażeń cron. Przecinek (,) umożliwia określenie wielu wartości (np. 0 8,12 * * * * uruchamia się o 8:00 i 12:00). Dywiz (-) definiuje zakres wartości (np. 1-5 od poniedziałku do piątku). Ukośnik (/) wskazuje wartości krokowe lub przyrosty (np. /5 w polu minut oznacza co 5 minut). Istnieją pewne niestandardowe rozszerzenia, takie jak znak zapytania (?), który może być używany w polach dnia miesiąca i dnia tygodnia, gdy jeden z nich jest określony, ale drugi nie jest istotny. Dodatkowo, niektóre implementacje obsługują szóste pole dla roku. Predefiniowane definicje harmonogramów, takie jak @yearly, @monthly, @weekly, @daily, @hourly oraz @reboot oferują wygodne skróty dla typowych harmonogramów.

Podczas konfigurowania zadań cron należy pamiętać o zmiennej PATH, ponieważ cron często działa w ograniczonym środowisku i wymaga pełnych ścieżek do poleceń i skryptów, aby uniknąć błędów. Przekierowanie danych wyjściowych (zarówno standardowego wyjścia, jak i standardowego błędu) do pliku dziennika jest dobrą praktyką służącą do monitorowania i debugowania zadań cron. Na przykład poniższy wpis przekierowuje zarówno dane wyjściowe, jak i błędy do określonego pliku dziennika:

Prostota Crona sprawia, że nadaje się on do różnych okresowych zadań. Na przykład, aby uruchamiać skrypt co godzinę, wpis cron miałby postać 0 * * * * * /ścieżka/do/skryptu.sh. W przypadku kopii zapasowych bazy danych zadanie cron można zaplanować tak, aby było uruchamiane codziennie o określonej godzinie, np.:

Należy jednak pamiętać o zagrożeniach bezpieczeństwa związanych z umieszczaniem haseł w takich poleceniach [4].

Wielu administratorów systemów używa crona do automatyzacji codziennego tworzenia kopii zapasowych baz danych w celu zapewnienia bezpieczeństwa danych. Chociaż sam cron nie obsługuje bezpośrednio rotacji logów, można go użyć do uruchomienia narzędzia logrotate [5]. Typowe zadanie cron, które uruchamia logrotate codziennie o 3 rano, może wyglądać jak niżej:

Godną uwagi cechą crona jest brak wbudowanego rejestrowania i monitorowania stanu, co wymaga od użytkowników ręcznej konfiguracji tych funkcji, często poprzez przekierowanie danych wyjściowych do plików.

Po uruchomieniu demon cron (crond) odczytuje systemowy plik crontab (zwykle /etc/crontab) i pliki crontab poszczególnych użytkowników (zwykle przechowywane w /var/spool/cron/). Analizuje te pliki, analizując każdy wpis zadania w celu określenia zaplanowanego czasu jego wykonania. Następnie Cron utrzymuje listę zdarzeń wszystkich zaplanowanych zadań, posortowaną według ich następnego czasu wykonania. Demon crond budzi się co minutę, aby sprawdzić, czy jakiekolwiek zadania z jego listy zdarzeń mają zostać uruchomione. Jeśli aktualny czas pasuje do harmonogramu zadania, Cron wykonuje odpowiednie polecenie lub skrypt w tle, korzystając z uprawnień użytkownika, który jest właścicielem wpisu crontab. Po wykonaniu cron ponownie oblicza następny czas uruchomienia zadania i aktualizuje swoją listę zdarzeń.

Timery systemd

Timery systemd są natywnym składnikiem systemu startowego systemd i menedżera usług, który stał się domyślny w wielu nowoczesnych dystrybucjach Linuksa. W przeciwieństwie do crona, który używa pojedynczego pliku do planowania, timery systemd działają poprzez aktywację powiązanych jednostek usług systemd. To rozdzielenie planowania (zdefiniowanego w pliku jednostki timera) i wykonywania (zdefiniowanego w pliku jednostki usługi) oferuje bardziej ustrukturyzowane i elastyczne podejście do automatyzacji [6]. Systemd zarządza timerami wraz z innymi usługami systemowymi, zapewniając ujednolicone ramy zarządzania i monitorowania za pomocą polecenia systemctl [7].

Architektura timerów systemd obejmuje dwa podstawowe pliki jednostek: jednostkę timera (.timer) i jednostkę usługi (.service) [8]. Jednostka timera określa, kiedy powiązana usługa powinna zostać aktywowana, a jednostka usługi definiuje akcję do wykonania.

Plik jednostki timera składa się zazwyczaj z trzech sekcji: [Unit], [Timer] i [Install]. Sekcja [Unit] zawiera ogólne informacje o timerze, takie jak jego opis i linki do dokumentacji. Sekcja [Timer] zawiera definicję harmonogramu. Kluczowe opcje obejmują OnCalendar do planowania opartego na kalendarzu (podobnego do wyrażeń cron), OnBootSec do wyzwalania po uruchomieniu systemu, OnUnitActiveSec do wyzwalania po ostatniej aktywności powiązanej usługi i inne. Opcja OnCalendar używa elastycznej składni przypominającej cron, ale z pewnymi różnicami, zgodnie z formatem [DzieńTygodnia] Rok-Miesiąc-Dzień Godzina:Minuta:Sekunda. Monotoniczne opcje timera, takie jak OnBootSec, definiują wyzwalacze oparte na przedziałach czasowych względem zdarzeń systemowych. Urządzenia IoT, które mogą nie mieć zainstalowanego crona, mogą wykorzystać OnBootSec do uruchomienia skryptu monitorującego kilka minut po każdym uruchomieniu, zapewniając stabilność systemu przed uruchomieniem skryptu.

Inne ważne opcje w sekcji [Timer] obejmują AccuracySec, która określa dokładność timera (domyślnie jest to jedna minuta, ale można ją ustawić na jedną sekundę lub nawet mikrosekundę). RandomizedDelaySec wprowadza losowe opóźnienie do czasu rozpoczęcia, co jest przydatne do zapobiegania jednoczesnemu wykonywaniu zadań w wielu systemach. W przypadku dużych wdrożeń serwerów można użyć RandomizedDelaySec do rozłożenia w czasie aktualizacji systemu lub zadań konserwacyjnych, zapobiegając nagłemu wzrostowi obciążenia zasobów centralnych. Persistent=true zapewnia, że jeśli zaplanowane zadanie zostanie pominięte z powodu systemu będącego w trybie offline, zostanie ono uruchomione przy następnym uruchomieniu systemu. Opcja Unit= określa jednostkę usługi, która będzie aktywowana przez ten licznik czasu. Wreszcie sekcja [Install] zazwyczaj zawiera opcję WantedBy=timers.target, która zapewnia włączenie timera podczas uruchamiania systemu.

Plik jednostki usługi (.service) definiuje rzeczywiste zadanie, które zostanie wykonane po uruchomieniu timera. Zawiera również sekcje takie jak [Unit], [Service], a czasami [Install] (choć [Install] jest mniej powszechne dla usług wyzwalanych przez timery). Sekcja [Unit] zawiera opis i zależności usługi (przy użyciu opcji takich jak Requires= i After=). Kluczową częścią jest sekcja [Service], gdzie ExecStart określa polecenie lub skrypt do wykonania [9]. W przypadku zadań, które są uruchamiane raz i kończone, powszechnie używany jest Type=oneshot. Opcja User= definiuje użytkownika, pod którym usługa będzie uruchamiana. Można również zdefiniować zasady ponownego uruchamiania, takie jak Restart=on-failure i RestartSec=.

Timery systemd są zarządzane przez główny proces systemd (PID 1). Jednostki timera (pliki .timer) są analizowane przez systemd, a ich harmonogramy są przechowywane. Systemd obsługuje dwa główne typy timerów: timery czasu rzeczywistego oparte na zdarzeniach kalendarza (przy użyciu OnCalendar) i monotoniczne timery oparte na przedziałach czasowych względem zdarzeń systemowych (takich jak OnBootSec lub OnUnitActiveSec). Gdy warunek wyzwolenia timera zostanie spełniony, systemd aktywuje powiązaną jednostkę usługową (plik .service). Ta aktywacja jest podobna do tego, jak systemd uruchamia każdą inną usługę. Systemd obsługuje również funkcje takie jak liczniki czasu Persistent, rejestrując ostatni czas wykonania i wyzwalając usługę przy następnym uruchomieniu, jeśli zaplanowane uruchomienie zostało pominięte. Ustawienie AccuracySec pozwala systemd na wprowadzenie niewielkiego opóźnienia w celu optymalizacji zużycia energii poprzez łączenie zdarzeń timera. RandomizedDelaySec dodaje losowe opóźnienie, aby zapobiec jednoczesnemu wykonywaniu tego samego zadania przez wiele systemów. Timery systemd są ściśle zintegrowane z journald w celu rejestrowania i przechwytywania standardowego wyjścia i standardowego błędu wyzwalanych usług [10].

Wymóg zarządzania dwoma plikami dla każdego zaplanowanego zadania z timerami systemd może początkowo wydawać się bardziej złożony w porównaniu do pojedynczego wpisu crontab crona. Separacja ta oferuje jednak lepszą organizację i modułowość, szczególnie w przypadku bardziej skomplikowanych scenariuszy automatyzacji.

Cron kontra Timery systemd

Porównując timery cron i systemd, w grę wchodzi kilka kluczowych aspektów, w tym elastyczność, wykorzystanie zasobów, bezpieczeństwo i rejestrowanie. Cron zapewnia proste planowanie oparte na czasie, które jest łatwe do zrozumienia dla podstawowych zadań. Jednak jego opcje planowania są nieco ograniczone, koncentrując się głównie na precyzji na poziomie minut. Określenie interwałów, które nie pokrywają się z godzinami lub dniami, może stanowić wyzwanie. Z kolei timery systemd oferują znacznie większą elastyczność. Obsługują one odmierzanie czasu z dokładnością do sekundy lub mikrosekundy i oferują różne typy wyzwalaczy, w tym zdarzenia kalendarzowe, monotoniczne timery względem zdarzeń systemowych, a nawet pośrednie wyzwalanie oparte na zdarzeniach poprzez zależności usług. Timery Systemd można skonfigurować tak, aby uruchamiały usługę 15 minut po uruchomieniu systemu za pomocą OnBootSec=15min i Persistent=true, funkcji niedostępnej natywnie w cron. Funkcje takie jak losowe opóźnienia i możliwość obsługi pominiętych zadań dodatkowo zwiększają elastyczność systemd.

Pod względem zużycia zasobów, zarówno cron, jak i systemd są ogólnie wydajne. Cron opiera się na pojedynczym demonie cron, który okresowo sprawdza zaplanowane zadania. Każde zadanie cron działa jako oddzielny proces. Timery systemd, będąc częścią większego ekosystemu systemd, nie zużywają znacznych zasobów, gdy są bezczynne. Usługi, które uruchamiają, będą zużywać zasoby na bazie ich zdefiniowanych działań. Warto zauważyć, że systemd zapewnia lepsze możliwości zarządzania zasobami dla tych usług dzięki integracji z cgroups, umożliwiając ustawienie limitów procesora i pamięci [11].

Bezpieczeństwo to kolejny krytyczny obszar porównania. Zadania Cron mogą stwarzać kilka zagrożeń dla bezpieczeństwa, w tym eskalację uprawnień z powodu błędnie skonfigurowanych uprawnień lub uruchamiania skryptów jako root, luki w PATH, jeśli nie są używane pełne ścieżki, warunki wyścigu z jednoczesnego wykonywania zadań, wstrzykiwanie skryptów, jeśli dane wejściowe nie są oczyszczane, oraz ryzyko związane z zakodowanymi na stałe danymi uwierzytelniającymi. Timery Systemd, dzięki powiązanym z nimi jednostkom usług, oferują solidniejsze ramy bezpieczeństwa. Funkcje takie jak NoNewPrivileges=yes zapobiegają uzyskiwaniu dodatkowych uprawnień przez usługi, ProtectSystem= montuje części systemu plików jako tylko do odczytu, ProtectHome= ogranicza dostęp do katalogów domowych użytkowników, a PrivateTmp= zapewnia izolowany dostęp do plików tymczasowych [12]. Te funkcje piaskownicy znacznie zwiększają poziom bezpieczeństwa zautomatyzowanych zadań w porównaniu do Crona. Jednostka usługi systemd dla serwera WWW może zawierać ProtectSystem=strict, aby zamontować cały system plików tylko do odczytu (z wyjątkiem niezbędnych katalogów), znacznie zmniejszając wpływ potencjalnego naruszenia bezpieczeństwa.

Cron zazwyczaj loguje się do dzienników systemowych, które mogą być nieuporządkowane i trudne do śledzenia. Dedykowane pliki dziennika i szczegółowe rejestrowanie często wymagają ręcznej konfiguracji. Cron nie ma wbudowanego monitorowania stanu. Z drugiej strony timery i usługi systemd są ściśle zintegrowane z journald, scentralizowanym systemem logowania systemd. Dzienniki są uporządkowane i łatwe do filtrowania według nazwy jednostki:

Systemd zapewnia również wbudowane monitorowanie stanu za pomocą poleceń takich jak systemctl status i systemctl list-timers, oferując wygodniejsze i bardziej szczegółowe debugowanie i śledzenie. Gdy timer systemd aktywuje usługę tworzenia kopii zapasowych, administratorzy mogą łatwo sprawdzić stan i dzienniki obu timerów i usługi, aby upewnić się, że tworzenie kopii zapasowej zakończyło się pomyślnie

Dodaj następującą linię do pliku crontab:

Zastąp /ścieżka/do/mojego/skryptu.sh rzeczywistą ścieżką do skryptu. Następnie zapisz i zamknij plik crontab.

Procedura wykorzystująca timery systemd [13] wymaga kilku dodatkowych kroków. Zacznij od utworzenia pliku jednostki usługi (Listing 1).

Zastąp /ścieżka/do/mojego/skryptu.sh rzeczywistą ścieżką do skryptu i myuser odpowiednim użytkownikiem. Poszukaj w Internecie opcji jednostki usługi.

Następnym krokiem jest utworzenie pliku jednostki czasowej (Listing 2). Odnieś się do strony man systemd.timer [6] dla opcji jednostki timera takich jak OnCalendar.

Następnie należy włączyć i uruchomić timer systemd za pomocą systemctl:

Kopia zapasowa bazy danych

Aby zaplanować tworzenie kopii zapasowej bazy danych, należy rozpocząć od utworzenia skryptu kopii zapasowej (Listing 3). Uczyń skrypt wykonywalnym za pomocą:

W cronie można skonfigurować zadanie cron, aby uruchamiać skrypt codziennie o 2 nad ranem. Otwórz plik crontab i dodaj następujący wiersz:

Jeśli używasz systemd, zacznij od utworzenia pliku jednostki usługi (Listing 4). Określ skrypt za pomocą ExecStart. Zastąp your_user odpowiednim użytkownikiem. Następnie utwórz plik jednostki timera (Listing 5), który będzie wyzwalany codziennie o godzinie 2AM przy użyciu OnCalendar. Następnie włącz i uruchom timer za pomocą systemctl:

Rotacja logów

Innym częstym zastosowaniem timera jest rotacja plików dziennika. Cron może uruchomić narzędzie logrotate. Aby rozpocząć, musisz upewnić się, że logrotate jest poprawnie skonfigurowany dla twoich logów w /etc/logrotate.conf lub poprzez pliki w /etc/logrotate.d/.

Aby uruchamiać logrotate codziennie o 3 rano, dodaj następującą linię do pliku crontab:

Systemd często zawiera timer rotacji logów (logrotate.timer), który aktywuje usługę logrotate.service. Aby sprawdzić, czy timer rotacji logów jest włączony, wprowadź następujące polecenie:

Jeśli licznik rotacji dziennika nie jest włączony, włącz go i uruchom:

W celu częstszej rotacji można utworzyć niestandardowe jednostki usług i timerów w katalogu /etc/systemd/system/ (Listingi 6 i 7). Włącz i uruchom niestandardowy timer za pomocą następujących poleceń:

Debugowanie timerów Cron i Systemd

W systemach systemd debugowanie zadań cron zazwyczaj obejmuje sprawdzenie statusu demona cron przy użyciu polecenia:

i przeglądanie dzienników systemowych (np. /var/log/syslog lub /var/log/cron) pod kątem wpisów związanych z cronem. Zapewnienie poprawnej składni, ewentualnie przy użyciu narzędzi takich jak Crontab.guru [14], oraz weryfikacja uprawnień skryptu i środowiska (PATH) są również kluczowe.

Debugowanie timerów systemd jest często prostsze dzięki zintegrowanym narzędziom. Status timera można sprawdzić za pomocą

i wyświetlić listę aktywnych timerów za pomocą:

Aby wyświetlić dzienniki usługi uruchomionej przez timer, napisz:

Błędy składni w plikach jednostek [15] sprawdzisz za pomocą:

Ręczne uruchomienie usługi może również pomóc w wyizolowaniu problemów z jej wykonaniem:

Zintegrowane polecenia rejestrowania i statusu w systemd zapewniają wygodniejsze i bardziej szczegółowe możliwości debugowania w porównaniu do polegania na dziennikach systemowych crona.

Wnioski

Zarówno cron, jak i timery systemd są wydajnymi narzędziami do automatyzacji zadań w Linuksie. Siła crona leży w jego prostocie i – ze względów historycznych – szerokiej kompatybilności, dzięki czemu nadaje się do prostego, opartego na czasie planowania, szczególnie w systemach innych niż systemd lub tam, gdzie pożądana jest minimalna złożoność. Timery Systemd oferują jednak bardziej nowoczesne, elastyczne i zintegrowane podejście. Ich szczegółowy czas, różnorodne mechanizmy wyzwalania, ulepszone funkcje bezpieczeństwa, solidne rejestrowanie za pośrednictwem journald i integracja z menedżerem usług systemd sprawiają, że timery systemd są doskonałym wyborem dla złożonej automatyzacji, precyzyjnych wymagań dotyczących harmonogramów i środowisk intensywnie wykorzystujących systemd.

Choć dwuplikowa struktura timerów systemd może początkowo wydawać się bardziej złożona, korzyści w zakresie organizacji, monitorowania, kontroli zasobów i bezpieczeństwa często przewyższają komplikacje, szczególnie w przypadku krytycznych lub skomplikowanych zadań w nowoczesnych środowiskach linuksowych. Wybór będzie ostatecznie zależeć od konkretnych wymagań zadania, środowiska operacyjnego oraz znajomości i poziomu zaznajomienia administratora z każdym systemem.

Info

[1] systemd: https://systemd.io/

[2] cron(8): https://man7.org/linux/man-pages/man8/cron.8.html

[3] crontab(5): https://man7.org/linux/man-pages/man5/crontab.5.html

[4] Nemeth, E., Snyder, G., Hein, T. R., & Whaley, A. Unix and Linux System Administration Handbook. Addison-Wesley Professional, 2017

[5] logrotate(8): https://man7.org/linux/man-pages/man8/logrotate.8.html

[6] systemd.timer(5): https://man7.org/linux/man-pages/man5/systemd.timer.5.html

[7] systemctl(1): https://man7.org/linux/man-pages/man1/systemctl.1.html

[8] systemd.unit(5): https://man7.org/linux/man-pages/man5/systemd.unit.5.html 

[9] systemd.service(5): https://man7.org/linux/man-pages/man5/systemd.service.5.html

[10] journalctl(1): https://man7.org/linux/man-pages/man1/journalctl.1.html

[11] systemd.resource-control(5): https://man7.org/linux/man-pages/man5/systemd.resource-control.5.html

[12] systemd.exec(5): https://www.freedesktop.org/software/systemd/man/systemd.exec.html

[13] Systemd/Timers: https://wiki.archlinux.org/title/Systemd/Timers

[14] Crontab.guru: https://crontab.guru/

[15] systemd-analyze(1): https://man7.org/linux/man-pages/man1/systemd-analyze.1.html