Jak utworzyć jednostkę serwisową SystemD w Linux

Chociaż SystemD był przedmiotem wielu kontrowersji, do tego stopnia, że ​​niektóre rozkłady zostały rozwidlone, aby się go pozbyć (patrz Devuan, widelca Debiana, który domyślnie zastępuje Systemda sysvinit), ostatecznie stał się on de-facto standardowy system init w świecie Linux.

W tym samouczku zobaczymy, jak ustrukturyzowana jest usługa systemu i nauczymy się, jak ją tworzyć.

W tym samouczku nauczysz się:

• Co to jest jednostka serwisowa…
• Jakie są sekcje jednostki serwisowej.
• Jakie są najczęstsze opcje, które można użyć w każdej sekcji.
• Jakie są różne rodzaje usług, które można zdefiniować.

Zastosowane wymagania i konwencje oprogramowania

SystemD System init

Wszystkie główne dystrybucje, takie jak Rhel, Centos, Fedora, Ubuntu, Debian i Archlinux, przyjęły systemd jako swój system inicjowy. W rzeczywistości Systemd jest czymś więcej niż tylko systemem init, i to jest jeden z powodów, dla których niektórzy ludzie są silnie sprzeczne z jego projektem, który jest sprzeczny z dobrze ustalonym motto UNIX: „Zrób jedno i zrób to dobrze”. Tam, gdzie inne systemy init używają prostego skryptu powłoki do zarządzania usługami, SystemD używa własnego .praca pliki (jednostki z .Sufiks serwisowy): W tym samouczku zobaczymy, jak są one ustrukturyzowane i jak tworzyć i zainstalować jeden.

Anatomia jednostki serwisowej

Co to jest jednostka serwisowa? Plik z .praca Sufiks zawiera informacje o procesie zarządzanym przez SystemD. Składa się z trzech głównych sekcji:

• [Jednostka]: Niniejsza sekcja zawiera informacje niezwiązane z typem urządzenia, takie jak opis usług
• [Usługa]: zawiera informacje o konkretnym typie urządzenia, w tym przypadku usługa
• [Instaluj]: Ta sekcja zawiera informacje o instalacji urządzenia

Przeanalizujmy każdy z nich szczegółowo.

Sekcja [jednostka]

[Jednostka] sekcja a .praca Plik zawiera opis samego urządzenia oraz informacje o jej zachowaniu i jego zależnościach: (aby poprawnie działać usługa może zależeć od innego). Tutaj omawiamy niektóre z najbardziej odpowiednich opcji, które można użyć w tej sekcji

Opcja „Opis”

Przede wszystkim mamy Opis opcja. Korzystając z tej opcji, możemy podać opis urządzenia. Opis pojawi się na przykład podczas dzwonienia Systemctl polecenie, które zwraca przegląd statusu SystemD. Tutaj jest, jak na przykład, jak opis httpd Usługa jest zdefiniowana w systemie Fedora:

[Jednostka] Opis = serwer Apache HTTP 

Opcja „po”

Za pomocą Po Opcja możemy stwierdzić, że nasza jednostka powinna zostać uruchomiona po podaniu jednostek w formie listy oddzielonej przestrzeni. Na przykład, ponownie obserwując plik usługi, w którym definiowana jest usługa internetowa Apache, możemy zobaczyć następujące:

Po = sieć.celowe zdalne fs.Target NSS-Hookup.Target Httpd-Init.praca

Wiersz powyżej instruuje SystemD, aby uruchomić jednostkę serwisową httpd.praca Dopiero po sieć, usuń-fs, NSS-Lookup cele i Usługa HTTPD-INIT.

Określenie twardych zależności za pomocą „wymagań”

Jak krótko wspomnialiśmy powyżej, jednostka (usługa w naszym przypadku) może zależeć od innych jednostek (niekoniecznie jednostek „serwisowych”), aby działać poprawnie: takie zależności można zadeklarować za pomocą korzystania z Wymaga opcja.

Jeśli którekolwiek z jednostek, od których usługa zależy trudne zależności. W tym wierszu, wyodrębnionym z pliku serwisowego Avahi-Daemon, możemy zobaczyć, jak jest on uzależniony od Avahi-Daemon.Jednostka gniazda:

Wymaga = avahi-daemon.gniazdo elektryczne

Deklarowanie „miękkich” zależności od „potrzeb”

Właśnie widzieliśmy, jak zadeklarować tak zwane „twarde” zależności od usługi, korzystając z Wymaga opcja; Możemy również wymienić „miękkie” zależności za pomocą Chce opcja.

Jaka jest różnica? Jak powiedzieliśmy powyżej, jeśli jakaś „trudna” zależność nie powiedzie się, usługa sama się nie powiedzie; Niepowodzenie jakiejkolwiek „miękkiej” zależności nie wpływa jednak na to, co dzieje się z jednostką zależną. W dostarczonym przykładzie możemy zobaczyć, jak doker.praca Jednostka ma miękką zależność od Docker-Storage-SETUP.praca jeden:

[Jednostka] Wants = Docker-Storage-Setup.praca 

Sekcja [Service]

w [Praca] sekcja a praca Jednostka, możemy określić rzeczy jako polecenie, które należy wykonać po uruchomieniu usługi lub typ samej usługi. Rzućmy okiem na niektóre z nich.

Rozpoczęcie, zatrzymanie i przeładowanie usługi

Usługa może być uruchamiana, zatrzymana, wznowiona lub ponownie załadowana. Polecenia, które należy wykonać podczas wykonywania każdego z tych działań, można określić za pomocą powiązanych opcji w [Praca] Sekcja.

Polecenie, które ma zostać wykonane po uruchomieniu usługi, jest zadeklarowane za pomocą ExecStart opcja. Argument przekazany do opcji może być również ścieżką do skryptu. Opcjonalnie możemy zadeklarować polecenia do wykonania przed i po uruchomieniu usługi, używając ExecStartPre I ExecTartPost odpowiednio opcje. Oto polecenie używane do rozpoczęcia usługi NetworkManager:

[Service] ExecStart =/usr/sbin/NetworkManager --No-Daemon 

W podobny sposób możemy określić polecenie, które ma zostać wykonane, gdy usługa zostanie ponownie załadowana lub zatrzymana, używając Execstop I ExecRoad opcje. Podobnie jak z tym, co dzieje się z ExecTartPost, polecenie lub wiele poleceń, które należy uruchomić po zatrzymaniu procesu, można określić za pomocą ExecStoppost opcja.

Rodzaj usługi

SystemD definiuje i rozróżnia niektóre różnego rodzaju usługi w zależności od ich oczekiwanego zachowania. Rodzaj usługi można zdefiniować za pomocą Typ Opcja, podając jedną z tych wartości:

• prosty
• rozwidlenie
• jeden strzał
• dbus
• notyfikować

Domyślny typ usługi, jeśli Typ I Busname Opcje nie są zdefiniowane, ale polecenie jest dostarczane za pośrednictwem ExecStart opcja, jest prosty. Po ustawieniu tego rodzaju usługi polecenie zadeklarowane ExecStart jest uważany za główny proces/usługa.

rozwidlenie Typ działa inaczej: polecenie dostarczone z ExecStart Oczekuje się, że rozwidli się i uruchomić proces potomny, który stanie się głównym procesem/usługą. Proces nadrzędny, którego ma umrzeć po zakończeniu procesu uruchamiania.

jeden strzał Typ jest używany jako domyślnie, jeśli Typ I ExecStart Opcje nie są zdefiniowane. Działa prawie jak prosty: Różnica polega na tym, że oczekuje się, że proces zakończy swoją pracę przed uruchomieniem innych jednostek. Jednostka jednak nadal jest uważana za „aktywną” nawet po wyjściu z polecenia, jeśli Resztki Opcja jest ustawiona na „Tak” (domyślnie to „nie”).

Następnym typem usługi jest dbus. Jeśli używany jest ten typ usługi, oczekuje się, że demon otrzyma nazwę od Dbus, Jak określono w Busname opcja, która w tym przypadku staje się obowiązkowa. Na resztę działa jak prosty typ. Kolejne jednostki są jednak uruchamiane dopiero po uzyskaniu nazwy DBUS.

Inny proces działa podobnie jak prosty, i to jest notyfikować: Różnica polega na tym, że demon ma wysłać powiadomienie za pośrednictwem sd_notify funkcjonować. Dopiero po wysłaniu tego powiadomienia uruchamiane są jednostki.

Ustaw limity czasu procesu

Korzystając z określonych opcji, możliwe jest zdefiniowanie czasu na usługi. Zacznijmy Restartsec: Korzystając z tej opcji, możemy skonfigurować ilość czasu (domyślnie w sekundach) SystemD powinien poczekać przed ponownym uruchomieniem usługi. TimePan może być również używany jako wartość dla tej opcji, jako „5 minut 20”. Domyślnie jest 100 ms.

TimeoutStartsec I Timeoutstopsec Można użyć opcji do określania odpowiednio limitu czasu na uruchomienie usług i zatrzymanie w sekundach. W pierwszym przypadku, jeśli po określonym czasie, proces uruchamiania demona nie zostanie ukończony, zostanie uznany za nieudany.

W drugim przypadku, jeśli usługa ma zostać zatrzymana, ale nie zostanie zakończona po określonym limicie czasu, najpierw a Sigterm A potem, po tym samym czasie, a Sigkill Sygnał są do niego wysyłane. Obie opcje akceptują również TimesPan jako wartość i można je jednocześnie skonfigurować, z skrótem: Timeoutsec. Jeśli nieskończoność jest dostarczany jako wartość, limity czasu są wyłączone.

Wreszcie możemy skonfigurować limit czasu czasu, w którym usługa może uruchomić za pomocą RuntimEMaxSec. Jeśli usługa przekroczy ten limit czasu, jest ona zakończona i uważana za nieudaną.

Sekcja [instalacja]

w [zainstalować] Sekcja możemy użyć opcji związanych z instalacją serwisową. Na przykład za pomocą Alias Opcja, możemy określić oddzieloną przestrzeń listę aliasów, które należy użyć do usługi podczas korzystania z poleceń SystemCtl (z wyjątkiem włączać).

Podobnie jak to, co dzieje się z Wymaga I Chce Opcje w [Jednostka] sekcja, w celu ustalenia zależności w [zainstalować] sekcja, możemy użyć Wymagane przez I Wanted. W obu przypadkach deklarujemy listę jednostek, które zależą od tego, co konfigurujemy: z pierwszą opcją będą one na niej trudne, przy czym te ostatnie będą uważane za jedynie jako słabe zależne od. Na przykład:

[Instalacja] WantedBy = Multi-User.cel 

Z powyższą linią oświadczyliśmy, że Multi-użytkownik Target ma miękką zależność od naszej jednostki. W terminologii systemowej jednostki kończące się .cel sufiks, może być powiązany z tak zwanym Runtimes w innych systemach init jako Sysvinit. W naszym przypadku cel wielu użytkowników, po osiągnięciu, powinien zawierać naszą usługę.

Tworzenie i instalowanie jednostki serwisowej

W systemie plików są w zasadzie dwa miejsca, w których instalowane są jednostki serwisowe Systemd: /usr/lib/systemd/system I /etc/systemd/system. Pierwsza ścieżka jest używana do usług świadczonych przez zainstalowane pakiety, podczas gdy drugi może być używany przez administratora systemu do własnych usług, które mogą zastąpić domyślne.

Utwórzmy niestandardowy przykład usługi. Załóżmy, że chcemy utworzyć usługę, która wyłącza funkcję Wake-Lan na określonym interfejsie Ethernet (ENS5F5 w naszym przypadku), kiedy zostanie uruchomiona, i ponownie biorą udział w tym, gdy zostanie zatrzymana. Możemy użyć ETHTOOL polecenie wykonania głównego zadania. Oto, jak może wyglądać nasz plik serwisowy:

[Jednostka] Opis = Force Ens5f5 Ethernet interfejs do 100 Mbps wymaga = sieć.Target po = sieć.Target [Service] Type = OneShot resztafterexit = tak execStart =/usr/sbin/ethtool -s end5f5 wol d execstop =/usr/sbin/ethtool -s end5f5 wol g [instalacja] Wantby = multi -user.cel 

Ustawiliśmy prosty opis jednostki i oświadczyliśmy, że usługa zależy od sieć.cel jednostka i powinna zostać uruchomiona po osiągnięciu. w [Praca] Sekcja ustawiamy rodzaj usługi jako jeden strzał, i poinstruował SystemD, aby uznał usługę za aktywność po wykonaniu polecenia za pomocą Resztki opcja. Zdefiniowaliśmy również polecenia, które mają zostać uruchomione po uruchomieniu i zatrzymaniu usługi. Wreszcie w [Zainstalować] Sekcja Zasadniczo oświadczyliśmy, że nasza usługa powinna być zawarta w Multi-użytkownik cel.

Aby zainstalować usługę, skopiujemy plik do /etc/systemd/system katalog as Wol.praca, Rozpoczniemy:

$ sudo cp wol.service/etc/systemd/system && sudo systemctl start wol.praca

Możemy sprawdzić, czy usługa jest aktywna, z następującym poleceniem:

$ SystemCtl is-Active Wol.Aktywne usługi 

Wyjście polecenia, zgodnie z oczekiwaniami, jest aktywny. Teraz, aby sprawdzić, czy „Wake on Lan” zostało ustawione D, I tak jest teraz wyłączone, możemy uruchomić:

$ sudo ethTool end5f5 | Grep Wake obsługuje budzenie: PG Wake-on: D 

Teraz zatrzymanie usługi powinno przynieść odwrotny wynik i ponownie włączyć WOL:

$ sudo systemCtl Stop Wol.Service && sudo ethtool end5f5 | grep budzenie obsługuje budzenie: PG Wake-on: G 

Wnioski

W tym samouczku zobaczyliśmy, w jaki sposób komponuje się plik serwisowy SystemD, jakie są jego sekcje i niektóre opcje, które można użyć w każdym z nich. Nauczyliśmy się skonfigurować opis usług, zdefiniować jego zależności i zadeklarować polecenia, które należy wykonać po uruchomieniu, zatrzymaniu lub przeładowaniu.

Ponieważ Systemd, jak to, czy nie, stał się standardowym systemem init w świecie Linux, ważne jest, aby zapoznać się z sposobem robienia rzeczy. Oficjalną dokumentację usług systemowych można znaleźć na stronie internetowej Freedesktop. Możesz także być zainteresowany przeczytaniem naszego artykułu na temat zarządzania usługami z SystemD.

Powiązane samouczki Linux:

• Rzeczy do zainstalowania na Ubuntu 20.04
• Rzeczy do zrobienia po zainstalowaniu Ubuntu 20.04 Focal Fossa Linux
• Jak zdenerwować Linuksa
• Mint 20: Lepsze niż Ubuntu i Microsoft Windows?
• Pobierz Linux
• Hung Linux System? Jak uciec do wiersza poleceń i…
• Rzeczy do zrobienia po zainstalowaniu Ubuntu 22.04 JAMMY Jellyfish…
• Wprowadzenie do automatyzacji, narzędzi i technik Linuksa
• Polecenia Linux: Top 20 najważniejsze polecenia, które musisz…
• Podstawowe polecenia Linux