Wyszukiwanie w witrynie

Jak tworzyć i uruchamiać nowe jednostki usług w Systemd


Kilka dni temu natknąłem się na 32-bitową dystrybucję Centos 8 i poczułem potrzebę przetestowania jej na starej maszynie 32-bitowej. Po uruchomieniu zdałem sobie sprawę, że wystąpił błąd i traciłem połączenie sieciowe, które musiałem ręcznie „uruchamiać” za każdym razem po uruchomieniu. Pytanie brzmiało: jak ustawić skrypt wykonujący to zadanie, uruchamiający się przy każdym uruchomieniu komputera?

Cóż, jest to bardzo proste i pokażę ci sposób działania systemu przy użyciu jednostek usługowych. Ale najpierw małe wprowadzenie do jednostek usługowych.

W tym artykule wyjaśnię, czym jest „jednostka usługowa” w systemie systemd i jak łatwo ją utworzyć i uruchomić. Spróbuję uprościć, czym są „cele”, dlaczego nazywamy je „zbiórami jednostek” i jakie są ich „potrzeby”. Na koniec korzystamy z jednostki serwisowej, która uruchamia nasz własny skrypt po procedurze rozruchu.

Jest oczywiste, że Twój komputer jest przydatny ze względu na oferowane przez niego usługi i aby mieć tę funkcjonalność, należy wywołać wiele usług podczas uruchamiania komputera i osiągania różnych poziomów.

Inne usługi są wywoływane do wykonania, gdy komputer osiągnie np. poziom ratunkowy (poziom działania 0), a inne, gdy osiągnie poziom wielu użytkowników (poziom działania 3). . Możesz sobie wyobrazić te poziomy jako cele.

W prosty sposób target to zbiór jednostek usługowych. Jeśli chcesz zobaczyć jednostki usług działające na Twoim poziomie graphical.target, wpisz:

systemctl --type=service

Jak widać, niektóre usługi są aktywne i „działają” przez cały czas, podczas gdy inne działają jednorazowo i kończą się (wychodzą).

Jeśli chcesz sprawdzić status usługi, możesz użyć polecenia systemctl, jak pokazano.

systemctl status firewalld.service

Jak widzisz, sprawdziłem status firewalld.service (tip: możesz użyć autouzupełniania nazwy usługi ). Informuje mnie, że usługa firewalld działa cały czas i jest włączona.

Włączona i wyłączona oznacza, że usługa zostanie trwale załadowana lub nie, odpowiednio podczas następnego uruchomienia. Z drugiej strony uruchamianie i zatrzymywanie usługi wiąże się z ograniczeniem bieżącej sesji i nie jest trwałe.

Na przykład, jeśli wpiszesz:

systemctl stop firewalld.service
systemctl status firewalld.service

Widać, że firewalld.service jest nieaktywny (martwy), ale nadal jest włączony, co oznacza, że podczas następnego uruchomienia zostanie załadowany. Jeśli więc chcemy, aby usługa była ładowana podczas rozruchu w przyszłości, musimy ją włączyć. Cóż za wspaniała konkluzja! Stwórzmy taki, to proste.

Jeśli przejdziesz do folderu:

cd /etc/systemd/system
ls -l

Możesz zobaczyć niektóre pliki linków do usług jednostkowych i niektóre katalogi „potrzeb” celu. Na przykład to, co cel wielu użytkowników chce załadować, gdy procedura rozruchu osiągnie swój poziom, jest wymienione w katalogu o nazwie /etc/systemd/system/multi-user.target.wants/ .

ls multi-user.target.wants/

Jak widać, zawiera nie tylko usługi, ale także inne cele, które również są zbiorami usług.

Stwórzmy jednostkę usługową o nazwie connection.service.

vim connection.service

i wpisz następujące polecenie (naciśnij „i ”, aby włączyć tryb wstawiania), zapisz go i wyjdź (za pomocą „esc ” i „:wq! ” ) :

[Unit]
Description = making network connection up
After = network.target

[Service]
ExecStart = /root/scripts/conup.sh

[Install]
WantedBy = multi-user.target

Aby wyjaśnić powyższe: stworzyliśmy jednostkę typu usługi (możesz także utworzyć jednostki typu docelowego) i ustawiliśmy ją tak, aby była ładowana po network.target (rozumiesz, że procedura startowa dociera do celów w określonej kolejności) i chcemy, aby za każdym razem, gdy usługa zacznie działać, wykonywał skrypt bashowy o nazwie conup.sh, który będziemy tworzyć.

Zabawa zaczyna się od ostatniej części [install]. Mówi, że będzie potrzebny „multi-user.target”. Jeśli więc włączymy naszą usługę, w folderze multi-user.target.wants zostanie utworzony symboliczny link do tej usługi! Rozumiem? A jeśli to wyłączymy, link zostanie usunięty. Tak prosty.

Po prostu włącz i sprawdź:

systemctl enable connection.service

Informuje nas, że zostało utworzone dowiązanie symboliczne w folderze multi-user.target.wants. Możesz potwierdzić, uruchamiając polecenie ls, jak pokazano.

ls multi-user.target.wants/

Jak widać „connection.service” jest gotowy do następnego uruchomienia, ale najpierw musimy utworzyć plik skryptu.

cd /root
mkdir scripts
cd scripts
vim conup.sh

Dodaj następującą linię wewnątrz Vima i zapisz ją:

#!/bin/bash
nmcli connection up enp0s3

Polecenie nmcli otwierające połączenie sieciowe dla interfejsu enp0s3.

Oczywiście, jeśli chcesz, aby Twój skrypt wykonał coś innego, możesz wpisać cokolwiek chcesz zamiast drugiej linii.

Na przykład,

#!/bin/bash
touch /tmp/testbootfile

co spowodowałoby utworzenie pliku w folderze /tmp (tylko w celu sprawdzenia, czy Twoja usługa działa).

Musimy także sprawić, aby skrypt był wykonywalny, uruchamiając polecenie chmod, jak pokazano.

chmod +x conup.sh

Teraz jesteśmy gotowi. Jeśli nie chcesz czekać do następnego uruchomienia (jest już włączone) możemy uruchomić usługę dla bieżącej sesji wpisując:

systemctl start connection.service

Voila! Moje połączenie działa!

Jeśli zdecydowałeś się napisać polecenie „touch /tmp/testbootfile ” w skrypcie, aby sprawdzić jego działanie, zobaczysz ten plik utworzony w folderze /tmp .

Naprawdę mam nadzieję, że pomogę ci zrozumieć, o jakie usługi, potrzeby, cele i uruchamianie skryptów podczas uruchamiania systemu chodzi.