Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



04.01.2022

Dane klientów HPE przejęte w...

HPE poinformowało, że dane klientów zostały przejęte w wyniku naruszenia dotyczącego jego...
04.01.2022

Bezpieczny dostęp

Citrix rozszerza swoje rozwiązania z zakresu bezpiecznego dostępu.
04.01.2022

Ochrona pracy zdalnej

Fortinet przedstawił spójną koncepcję zabezpieczania środowiska IT w firmach, które...
04.01.2022

Rozwiązania dla Linuxa

Red Hat poinformował o udostępnieniu rozwiązania Red Hat Enterprise Linux 8.5.
04.01.2022

Usługi chmurowe

Strefa lokalna AWS w Polsce
04.01.2022

Nowy laptop należący do serii...

ASUS VivoBook Pro 16X to nowy laptop należący do popularnej serii VivoBook. Przeznaczony...
04.01.2022

Do fizycznej wirtualizacji...

QNAP zaprezentował urządzenie nowej generacji do wirtualizacji sieci – QuCPE-7012 –...
04.01.2022

Dla przemysłu

Transcend prezentuje bezpieczne dyski SSD zgodne ze standardem Opal SSC 2.0. Oba dyski...
04.01.2022

SI w monitoringu

Firma i-PRO, mająca swoje korzenie w Panasonic, wprowadziła do swojej serii S kamery typu...

Harmonogram zadań – alternatywy dla Crona

Data publikacji: 20-12-2018 Autor: Konrad Kubecki
Polecenie systemctl...

Cron uchodzi za oczywiste narzędzie do uruchamiania zadań cyklicznych w systemach Linux i jeden z kluczowych elementów tego systemu operacyjnego. Tymczasem istnieją narzędzia alternatywne realizujące podobne funkcje. Są nimi timery zaimplementowane jako jedna ze składowych menadżera usług systemd oraz daemon atd.

 

Timery służą do uruchamiania usług zgodnie z określonym harmonogramem. W ramach usługi może być wykonywane pojedyncze polecenie lub złożony skrypt. Różnica w konfiguracji timerów i zadań crona jest znaczna, a w niniejszym artykule przybliżymy tematykę timerów na prostych przykładach.


> SYSTEMD

Podstawową cechą timerów jest możliwość tworzenia zadań cyklicznych w formie usług systemowych. Dzięki temu zarządzanie skryptem obudowanym w harmonogram odbywa się w sposób bardzo podobny do sterowania usługami takimi jak choćby httpd, sshd i smb. Warunkiem użycia timerów jest obecność w systemie menadżera usług systemd. Jest on fundamentalnym elementem wielu współczesnych dystrybucji Linuksa: RedHat, CentOS, Fedora, Debian, Ubuntu, Arch Linux i wiele więcej.

Samo użycie najnowszych wersji tych dystrybucji oznacza obecność systemd. Nie są wymagane żadne dodatkowe kroki konfiguracyjne. Systemd jest następcą SysV i obsługuje stare, typowe dla SysV polecenia. Przykładowo jeśli użyjemy polecenia service nazwa_uslugi restart, to systemd potrafi wykonać taką operację, mimo że poprawna dla niego metoda przeładowania usługi to systemctl restart httpd.

Systemd zarządza usługami, wykonując wiele czynności:

 

  • start/stop/restart usług;
  • prezentowanie statusu usług;
  • raportowanie błędów związanych z nieudanym startem lub nieoczekiwanym wyłączeniem;
  • równoległe startowanie wielu usług podczas uruchamiania systemu operacyjnego;
  • zachowanie odpowiedniej kolejności startu, gdy konfiguracja wybranych usług jasno określa zależności między nimi.


> PRZYKŁAD UTWORZENIA TIMERA

1. Pierwszym krokiem do utworzenia działającego timera jest napisanie skryptu, który będzie uruchamiany zgodnie z określonym harmonogramem. Zadanie realizowane przez skrypt może polegać na zapisywaniu w dzienniku aktualnej godziny.

Założenie: systemd uruchamia skrypt co minutę. Do logu powinna odkładać się godzina w postaci HH:MM:SS. Treść skryptu może wyglądać następująco:

 



Skrypt wymaga odpowiednich uprawnień:



2. Utworzony skrypt należy „ubrać” w plik konfiguracyjny usługi rozumianej przez systemd. Plik powinien znaleźć się w katalogu /usr/lib/systemd/system/ i mieć rozszerzenie *.ser­vice. Treść pliku test.service to:

[Unit]
Description=Testowy serwis do uruchamiania skryptu


[Service]
Type=simple
ExecStart=/bin/bash /root/testowo.sh
[Install]
WantedBy=multi-user.target

W sekcji [Unit] opcja description to opis usługi. Powinna zawierać nazwę oraz treść określającą w kilku słowach działanie skryptu. Będzie to widoczne podczas późniejszego sterowania usługą oraz w dziennikach systemowych. Jednoznaczność opisu ułatwia późniejsze zarządzanie oraz diagnostykę, dlatego warto postarać się o jego jakość. Będzie on prezentowany na ekranie np. podczas sprawdzania stanu usługi poleceniem systemd status test.

Sekcja [Service] zawiera parametr Type oraz ExecStart. Pierwszy z nich opisuje charakterystykę uruchamiania usługi. Wybrany w tym przypadku simple oznacza, że skrypt stworzony w kroku nr 1 jest głównym skryptem usługi, nie uruchamia procesu potomnego, który mógłby przejąć rolę głównego procesu usługi. ExecStart określa, co dokładnie ma być uruchomione podczas startowania usługą.

3. Kolejny etap to utworzenie pliku z rozszerzeniem *.timer. Powinien być ulokowany w tym samym katalogu, w którym znajduje się plik test.service, i mieć nazwę test.timer. Zalecane jest, aby plik usługi oraz plik timera zawierały tę samą nazwę, a różniły się jedynie rozszerzeniem.

 

[...]

 

Specjalista ds. utrzymania infrastruktury i operacji. Zajmuje się problematyką budowy i utrzymania centrów przetwarzania danych oraz zarządzania nimi i koordynowaniem zmian dotyczących krytycznej infrastruktury IT. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"