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



22.03.2019

Pożegnanie z systemem Windows...

System operacyjny Windows 7 wciąż cieszy się dużą popularnością wśród użytkowników...
22.03.2019

Segmentacja sieci

Fortinet FortiGate 3600E, 3400E, 600E i 400E
22.03.2019

Monitoring IP

TP-Link TL-SL1218MP
22.03.2019

Efektywność energetyczna

UPS Eaton 93E
21.02.2019

Wdrażanie projektów AI

Infrastruktura OVH
21.02.2019

Certyfikacja kluczy

HEUTHES-CAK
21.02.2019

Kopie zapasowe

Veeam Availability for AWS
21.02.2019

Dysk SSD Samsung 970 EVO Plus

Dysk SSD Samsung 970 EVO Plus
21.02.2019

Szyfrowane USB

Kingston IronKey D300 Serialized

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"