Jak skonfigurować usługę Linux, aby uruchamiała się automatycznie po restarcie lub awarii systemu: Część 2 (Wyjaśnienia teoretyczne)

W tej drugiej części dwuczęściowego poradnika dotyczącego konfiguracji usług systemu Linux tak, aby uruchamiały się automatycznie po restarcie lub awarii systemu, szczegółowo omówimy system init. Możesz zapoznać się z częścią 1 serii: Jak skonfigurować usługę Linux do automatycznego uruchamiania po restarcie lub awarii systemu: Praktyczne przykłady tutaj.

Bieżący poradnik będzie zawierał dużo teorii. Dlatego należy traktować go jako punkt odniesienia, aby lepiej zrozumieć, jak działa system init w systemie Linux. W pierwszej części tego poradnika udostępniliśmy fragmenty kodu i skrypty startowe, które system init odczytuje podczas uruchamiania. Użyliśmy również MySQL jako przykładu, aby dowiedzieć się, jak włączyć i wyłączyć automatyczne uruchamianie usługi Linux po awarii lub restarcie. Jak dowiedziałeś się w pierwszej części tego dwuczęściowego poradnika, w różnych dystrybucjach Linuksa stosowane są trzy systemy init: System V, Upstart i Systemd. Możesz odnieść się do pierwszej części tego poradnika, aby zrozumieć, która dystrybucja i wersja jest skonfigurowana do korzystania z określonego systemu init.

W tym poradniku wyjaśnimy kod, którego użyliśmy w pierwszej części. Szczegółowo omówimy polecenia i pliki konfiguracyjne, z których korzysta system init. Zaczynajmy!

Wymagania wstępne

Podsumowując pierwszą część tego dwuczęściowego poradnika, wspomnieliśmy, że należy pozostawić trzy serwery testowe uruchomione. Jeśli je usunąłeś, możesz wrócić i utworzyć je ponownie. Pomoże Ci to śledzić kroki w tym poradniku. Trzy serwery testowe, które powinieneś posiadać, to:

• Ubuntu 9.04 i starsze lub Debian 6 x64 (użyjemy go do zademonstrowania systemu init System V)
• Ubuntu 14.04 x64 (użyjemy go do zademonstrowania Upstart). Oto poradnik, jak łatwo skonfigurować serwer Ubuntu.
• CentOS 7 x64 (użyjemy go do zademonstrowania Systemd).

Na każdym z serwerów, których użyjesz do uruchamiania poleceń, powinieneś mieć użytkownika z uprawnieniami sudo. Ten poradnik dotyczący konfiguracji pliku sudoers w systemie Linux może Ci pomóc.

Uwaga:  Polecenia w tym poradniku będą ingerować w usługi systemowe. Dlatego nie należy ich stosować na działającym serwerze produkcyjnym.

Poziomy uruchomienia

Poziom runlevel to poziom operacyjny, który opisuje bieżący stan systemu Linux w odniesieniu do dostępnych usług. Koncepcja ta wywodzi się z init System V. Gdy system Linux się uruchamia, inicjuje jądro, wchodzi w jeden poziom uruchomienia i uruchamia skrypt startowy powiązany z tym poziomem. Podczas startu systemu można wykonać tylko jeden poziom uruchomienia.

Inne przykłady poziomów uruchomienia obejmują stan wyłączenia, tryb restartu, tryb pojedynczego użytkownika itp. Każdy poziom określa, jakie usługi mają być uruchamiane w tym stanie. Niektóre usługi mogą działać na więcej niż jednym poziomie, podczas gdy inne nie.

Istnieje siedem poziomów uruchomienia: od 0 do 6. Poniżej znajduje się definicja tych siedmiu poziomów:

• Poziom uruchomienia 0: Wyłączenie systemu
• Poziom uruchomienia 1: Tryb pojedynczego użytkownika i tryb ratunkowy
• Poziomy uruchomienia 2, 3, 4: Tryb wieloużytkownikowy i tekstowy z włączoną siecią
• Poziom uruchomienia 5: Tryb wieloużytkownikowy, z obsługą sieci i trybem graficznym
• Poziom uruchomienia 6: Restart systemu

Poziomy uruchomienia niekoniecznie są wykonywane sekwencyjnie. Poziomy 2, 3 i 4 różnią się w zależności od używanej dystrybucji Linuksa. W niektórych dystrybucjach można zaimplementować poziom 4, a w innych nie. Kiedy włączyłeś automatyczne uruchamianie usługi, jak wyjaśniono w części pierwszej, w rzeczywistości dodałeś ją do poziomu uruchomienia. W System V system operacyjny uruchamia się z określonym poziomem uruchomienia, a podczas startu próbuje uruchomić wszystkie usługi powiązane z tym poziomem. Poziomy uruchomienia są celami (targets) w Systemd, co omówimy w sekcji poświęconej Systemd.

Init i PID 1

System init to pierwszy proces, który uruchamia się po starcie systemu Linux i załadowaniu jądra do pamięci. Wykonuje on różne zadania, w tym określa, w jaki sposób i w jakiej kolejności proces użytkownika lub usługa systemowa zostaną załadowane oraz czy powinny uruchamiać się automatycznie. W każdej dystrybucji Linuksa każdy proces jest identyfikowany przez identyfikator procesu (PID), a init ma PID równy 1. Jest on rodzicem wszystkich innych procesów, które kolejno uruchamiają się podczas startu systemu.

Historia init

System init znajdujący się w najnowszych dystrybucjach Linuksa stanowi ulepszenie pierwotnego rozwiązania. Najwcześniejsze wersje dystrybucji Linuksa korzystały z init System V, który był podobnie używany w systemach Unix. W miarę rozwoju Linuksa wdrożono demona init Upstart – został on stworzony przez Ubuntu. Obecnie (w momencie pisania tego samouczka, 2021 r.) mamy demona init Systemd – został on po raz pierwszy wdrożony przez Fedora. Ponieważ systemy Linux stale się rozwijają, w przyszłości może pojawić się nowszy system init. W tym samouczku omówimy te trzy: System V, Upstart i Systemd.

Najnowsze wersje Linuksa są domyślnie wyposażone w system init Systemd. Zachowano jednak starsze systemy init w celu zapewnienia wstecznej kompatybilności. Istnieją różne implementacje System V, których można używać w innych wariantach Linuksa. Na przykład FreeBSD, wariant systemu UNIX, używa BSD init. Starsze wersje Debiana używają SysVinit. Oba wywodzą się z System V.

Sposób, w jaki każda wersja demona init zarządza usługami, jest inny. Ulepszenia wprowadzane w każdej wersji miały na celu stworzenie solidnego narzędzia do zarządzania usługami, które poradziłoby sobie ze wszystkim, czego system Linux potrzebuje w zakresie usług, urządzeń, portów i innych zasobów. Istniała potrzeba stworzenia potężnego systemu, który mógłby ładować zasoby równolegle i który potrafiłby w elegancki sposób odzyskać sprawność po awarii systemu.

Sekwencja uruchamiania System V Init

System V wykorzystuje plik inittab do przechowywania instrukcji inicjalizacyjnych. Upstart zachowuje plik inittab w celu zapewnienia wstecznej kompatybilności. Oto schemat uruchamiania System V:

• System init pochodzi z pliku binarnego /sbin/init.
• Po załadowaniu systemu init do pamięci, odczytuje on swój pierwszy plik w /etc/inittab.
• Jeden z wpisów w tym pliku określa poziom uruchomienia (runlevel), w którym maszyna powinna się uruchomić. Na przykład, jeśli wartość poziomu uruchomienia jest określona jako 5, Linux uruchomi się w trybie wieloużytkownikowym, graficznym z włączoną siecią (częste w dystrybucjach przeznaczonych do użytku na komputerach stacjonarnych). Określony tutaj poziom uruchomienia jest znany jako domyślny poziom uruchomienia, ponieważ to on będzie zawsze używany.
• Następnie system init zagląda dalej do pliku /etc/inittab i odczytuje, jakie skrypty init musi uruchomić dla tego poziomu uruchomienia.

Znajdując skrypty do uruchomienia dla danego poziomu uruchomienia, system init określa, jakie usługi musi uruchomić. W tych skryptach init zazwyczaj konfiguruje się zachowanie startowe poszczególnych usług, w ten sam sposób, w jaki skonfigurowaliśmy usługę MySQL w pierwszej części tego samouczka.

Struktura skryptów init System V

W tej sekcji szczegółowo przyjrzymy się skryptom init. Pliki konfiguracyjne System V lub skrypty init to elementy kontrolujące usługi. Skrypty init inicjalizują usługę, stąd nazwa skrypt init.

Każda usługa ma swój własny skrypt init. Na przykład skrypt init MySQL kontroluje serwer MySQL. Dostawcy aplikacji dostarczają skrypty init dla swoich konkretnych aplikacji, podczas gdy natywne usługi Linuksa są dostarczane wraz z instalacją systemu operacyjnego. Tworząc niestandardową aplikację, możesz również utworzyć dla niej własne, niestandardowe skrypty init.

Aby uruchomić usługę taką jak serwer MySQL, jej program binarny jest najpierw ładowany do pamięci. W zależności od konfiguracji program może nadal działać w tle, aby akceptować połączenia klienckie. Skrypt init usługi obsługuje zadanie uruchamiania, zatrzymywania lub ponownego ładowania aplikacji binarnej. Skrypty init w System V to skrypty powłoki. Inną ich nazwą są skrypty rc (run command).

Struktura katalogów System V

Katalogiem nadrzędnym dla skryptów init jest katalog /etc. Katalog /etc/init.d jest właściwym katalogiem dla skryptów powłoki init. Skrypty te są powiązane dowiązaniami symbolicznymi z katalogami rc.

W katalogu /etc znajduje się kilka katalogów rc, z których każdy ma numer w swojej nazwie. Liczby te reprezentują różne poziomy uruchomienia. Jeśli wylistujesz zawartość tego katalogu, zobaczysz nazwy takie jak /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, itp.

Jeśli przejrzysz zawartość każdego z katalogów rc, zobaczysz pliki zaczynające się od K lub S w ich nazwie pliku, a po nich następują dwie cyfry. Pliki te zawierają dowiązania symboliczne wskazujące z powrotem na rzeczywiste skrypty powłoki init rzeczywistego programu. Litery K i S to skróty: K oznacza Kill lub Stop, podczas gdy S oznacza Start. Dwie cyfry w nazwach plików reprezentują kolejność wykonywania. Jeśli zobaczysz plik o nazwie K05script_name, zostanie on wykonany przed plikiem o nazwie K09script_name.

Uruchamianie

Przechodząc dalej w sekwencji uruchamiania, zobaczmy, jak wywoływane są skrypty init.

Skrypty S i K nie są wywoływane bezpośrednio przez system init. Są one raczej wywoływane przez inny skrypt: /etc/init.d/rc. Plik /etc/inittab instruuje demona init, na którym poziomie uruchomienia system powinien domyślnie się uruchomić. W zależności od określonego poziomu uruchomienia, linia w pliku /etc/inittab wywołuje skrypt /etc/init.d/rc, przekazując domyślny poziom uruchomienia jako parametr. Używając tego parametru, skrypt wywoła pliki w odpowiednim katalogu /etc/rcN.d, gdzie N oznacza poziom uruchomienia. Na przykład, jeśli serwer uruchamia się na poziomie 5, wywołane zostaną odpowiednie pliki w katalogu /etc/rc5.d.

Wewnątrz katalogu rc wszystkie skrypty K są uruchamiane numerycznie z argumentem stop, podczas gdy wszystkie skrypty S są uruchamiane analogicznie z argumentem start. Odpowiednie rzeczywiste skrypty powłoki init dla programu, do którego prowadzą dowiązania symboliczne w /etc/rcN.d, zostaną wywołane z parametrami stop i start odpowiednio.

Mówiąc najprościej, za każdym razem, gdy system Linux wchodzi na określony poziom uruchomienia lub przełącza się na niego, uruchamiane są określone skrypty w celu zatrzymania niektórych usług, podczas gdy inne są uruchamiane w celu włączenia innych usług. Proces ten zapewnia, że każdy proces, który nie powinien działać w danym stanie Linuksa, zostanie zatrzymany, a każdy proces, który powinien działać, zostanie uruchomiony automatycznie.

Automatyczne uruchamianie System V

Gdy włączasz automatyczne uruchamianie usługi podczas rozruchu, bezpośrednio modyfikujesz zachowanie init. Na przykład, jeśli skonfigurujesz usługę do automatycznego uruchamiania na poziomie 2, proces init utworzy odpowiednie dowiązania symboliczne w katalogu /etc/rc2.d. Aby pomóc Ci to zrozumieć, wyjaśnimy to na przykładzie.

Przykład System V

Aby podać praktyczny przykład, użyjemy konfiguracji usługi MySQL z części 1. Zaloguj się więc na VPS z systemem Debian 6 jako użytkownik sudo/root za pomocą ssh (lub putty, jeśli korzystasz z systemu Windows) i wykonaj następujące kroki.

Krok 1: Otwarcie i zbadanie pliku inittab

Najpierw wprowadź następujące polecenie, aby wyświetlić zawartość pliku inittab w terminalu:

Zawartość pliku powinna wyglądać mniej więcej tak:

Liczba 2 oznacza poziom uruchomienia, z którym startuje system. W tym przypadku poziom 2 jest domyślny, stąd ten system Debian uruchomi się na poziomie 2 w trybie wieloużytkownikowym, tekstowym. Możesz uruchomić następujące polecenie, aby to potwierdzić:

Pokaże dane wyjściowe podobne do:

Krok 2: Badanie katalogów rc

ls -ld /etc/rc*.d

Jak widzieliśmy wcześniej w pliku inittab, system jest skonfigurowany do uruchamiania się na

runlevelpoziomie uruchomienia 2, stąd skrypty w katalogu /etc/rc2.d zostaną wykonane przy uruchamianiu systemu. Możesz wyświetlić zawartość tego katalogu za pomocą polecenia:

Jak widać z danych wyjściowych, pliki te są jedynie dowiązaniami symbolicznymi wskazującymi na rzeczywiste pliki skryptów w /etc/init.d. Oto fragment danych wyjściowych:

W tym katalogu nie ma skryptów K, są tylko skrypty S (startowe). Skrypty te uruchomią powiązane tutaj usługi, takie jak rsync. Można również zauważyć usługę mysql, która została wymieniona i którą omówimy w następnym podpunkcie.

Krok 3: Badanie skryptu init

Gdy instalowana jest usługa zgodna z System V, tworzy ona skrypt powłoki w katalogu /etc/init.d. Możesz sprawdzić dostępność skryptu powłoki MySQL, wprowadzając następujące polecenie:

Pokazuje poniższy wynik:

Plik jest dość duży. Możesz wprowadzić następujące polecenie, aby wyświetlić jego zawartość:

Krok 4: Używanie chkconfig lub sysv-rc-conf

Chkconfig to polecenie, którego można użyć w dystrybucjach opartych na RHEL, takich jak CentOS, aby włączyć lub wyłączyć usługi zgodne z System V. Możesz go również użyć do wyświetlenia listy zainstalowanych usług i ich odpowiednich poziomów uruchomienia. Oto polecenie do tego (działa na CentOS):

W dystrybucjach Debiana takie narzędzie nie istnieje natywnie. Program update-rc.d w systemach Debian tylko instaluje i usuwa usługi z poziomów uruchomienia. Dostępne jest niestandardowe narzędzie, którego można użyć do przeniesienia funkcjonalności chkconfig do systemów Debian. Wprowadź następujące polecenie, aby je zainstalować:

Po zainstalowaniu możesz uruchomić następujące polecenie, aby wyświetlić zachowania poziomów uruchomienia dla różnych usług:

Wynik tego polecenia jest sformatowany w tabelę, która pokazuje nazwę usługi po lewej stronie oraz poziom uruchomienia, na którym usługa działa:

Znak X wskazuje poziom uruchomienia, na którym usługa będzie działać. To narzędzie umożliwia wyłączenie lub włączenie usługi dla danego poziomu uruchomienia za pomocą klawiszy strzałek i spacji. Aby wyjść z narzędzia, naciśnij Q.

Krok 5: Przetestowanie zachowania MySQL podczas uruchamiania systemu

Na powyższym zrzucie ekranu widać, że usługa mysql jest włączona na poziomach uruchomienia 2,3,4,5. Możesz wyłączyć MySQL za pomocą następującego polecenia:

Wynik wygląda następująco. Zauważ, że usługa została zatrzymana dla wszystkich poziomów uruchomienia:

Uruchom poniższe polecenie, aby zobaczyć zawartość katalogu:

Zobacz linię mysql w poniższym wyniku:

Wynik pokazuje, że dowiązanie symboliczne zmieniło się na K, co oznacza Kill (zatrzymaj). W związku z tym MySQL nie uruchomi się automatycznie domyślnie na poziomie uruchomienia 2. Dzieje się tak za każdym razem, gdy włączasz lub wyłączasz usługę w System V. Dopóki w katalogu domyślnego poziomu uruchomienia usługi znajduje się skrypt S (start), demon init uruchomi tę usługę podczas startu systemu.

Aby ponownie włączyć usługę, wprowadź następujące polecenie:

Krok 6: Przetestowanie zachowania MySQL po awarii systemu

W tej sekcji omówimy, jak System V radzi sobie z awariami usług. Możesz wykorzystać tę wiedzę do skonfigurowania zachowania własnych usług po awarii.

W pierwszej części tego samouczka wprowadziliśmy zmianę w pliku /etc/inittab, aby umożliwić automatyczne uruchamianie MySQL po awarii. Dodaliśmy następującą linię, aby włączyć to zachowanie:

Możemy sprawdzić to zachowanie, wykonując kilka testów. Najpierw zrestartuj swój serwer VPS, wprowadzając następujące polecenie:

Po restarcie sprawdź, z jakimi identyfikatorami procesów (PID) działają mysql_safe i mysqld, wprowadzając następujące polecenie, aby uzyskać identyfikatory procesów:

Otrzymany wynik to:

Zanotuj identyfikatory procesów (PID). W naszym przypadku były to 1836 i 186338. Teraz zasymuluj awarię, zabijając proces za pomocą przełącznika -9, wprowadzając następujące polecenie. Pamiętaj, aby zastąpić je swoimi identyfikatorami procesów:

Po kilku minutach sprawdź status MySQL, uruchamiając następujące polecenie:

Dane wyjściowe wskazują, że MySQL działa, co oznacza, że został on ponownie uruchomiony po zasymulowanej awarii. Jeśli uruchomisz ponownie polecenie ps -ef | grep mysql, zobaczysz, że oba procesy mysqld_safe i mysqld działają, aczkolwiek z nowymi identyfikatorami.

Możesz spróbować zabić te procesy wielokrotnie, a zostaną one ponownie uruchomione po kilku minutach. Takie zachowanie jest możliwe dzięki linii, którą dodaliśmy do pliku /etc/inittab. W ten sposób konfiguruje się usługi do automatycznego restartu po awarii w System V. Aby ponownie zapoznać się ze składnią, zajrzyj do części 1 tego samouczka.

Niektóre niestandardowe usługi mogą zawierać błędy i nie uruchomić się ponownie po wielu próbach. Demon init spróbuje ponownie uruchomić usługę, ale jeśli nie uda się to więcej niż dziesięć razy w ciągu dwóch minut, system Linux wyłączy usługę na maksymalnie 5 minut. Pomaga to utrzymać stabilność systemu i zapobiega marnowaniu zasobów systemowych na ulegające awariom usługi. Dobrym pomysłem jest sprawdzenie logów systemowych w celu zidentyfikowania problemów z niestandardowymi aplikacjami, które wymagają naprawy.

Wprowadzenie do Upstart

System inicjalizacji System V przez długi czas był kluczowy dla dystrybucji Linuksa. Jednak, jak to bywa z technologią, stale się ona rozwija. Ekosystem Linuksa rozrósł się ogromnie dzięki wsparciu społeczności open-source. System V ładuje zadania i usługi w sposób szeregowy, co wprowadza złożoność i pochłania czas. Dodatkowo, wprowadzenie nowoczesnych, wymiennych nośników pamięci, do obsługi których System V nie był zaprojektowany, wywołało potrzebę stworzenia innego systemu inicjalizacji.

Deweloperzy Ubuntu rozpoczęli prace nad innym systemem inicjalizacji. Ten system init został zaprojektowany tak, aby zapewnić szybsze ładowanie systemu operacyjnego, zagwarantować poprawne czyszczenie po awariach usług, utrzymać przewidywalność zależności między usługami systemowymi oraz uwzględnić wymienne nośniki pamięci. Tak narodził się demon Upstart.

Upstart init ma kilka zalet w porównaniu z System V init, do których należą:

• Upstart nie ładuje usług szeregowo jak System V, co skraca czas uruchamiania systemu.
• Został zaprojektowany tak, aby lepiej radzić sobie z awariami usług dzięki poprawnemu czyszczeniu i ponownemu uruchamianiu usług.
• Upstart wykorzystuje elastyczny system zdarzeń do dostosowywania obsługi usług w różnych stanach.
• Ten system init unika skomplikowanych skryptów powłoki do ładowania i zarządzania usługami, jakie występują w System V. Upstart używa prostych plików konfiguracyjnych, które są łatwe do zrozumienia i modyfikacji.
• Upstart został zbudowany z myślą o kompatybilności wstecznej. Skrypt /etc/init.d/rc nadal działa, aby zarządzać natywnymi usługami System V.
• Unika on utrzymywania nadmiarowych dowiązań symbolicznych, z których wszystkie wskazują na ten sam skrypt.

Zdarzenia Upstart

Upstart opiera się na zdarzeniach, co pozwala na powiązanie wielu zdarzeń z tą samą usługą. Ta architektura oparta na zdarzeniach zapewnia elastyczne zarządzanie usługami. Każde zdarzenie może wywołać skrypt powłoki specyficzny dla danego zdarzenia.

Zdarzenia Upstart obejmują:

• Starting
• Started
• Stopping
• Stopped

Pomiędzy zdarzeniami usługa może znajdować się w różnych stanach, w tym między innymi:

• Waiting
• Pre-start
• Starting
• Post-start
• Running
• Pre-stop
• Stopping
• Post-stop

Upstart init można skonfigurować tak, aby podejmował działania dla każdego z tych stanów, stąd jego elastyczna konstrukcja.

Sekwencja startowa Upstart Init

Upstart init uruchamia skrypt /etc/init.d/rc podczas uruchamiania, podobnie jak System V. Skrypt ten normalnie uruchamia wszelkie skrypty init System V, aby zapewnić kompatybilność wsteczną.

Pliki konfiguracyjne Upstart znajdują się w katalogu /etc/init, więc domyślnie tam zagląda i wykonuje polecenia powłoki znajdujące się w plikach konfiguracyjnych w tym katalogu.

Pliki konfiguracyjne Upstart

System inicjalizacji Upstart używa plików konfiguracyjnych usług do kontrolowania usług, w przeciwieństwie do skryptów bash używanych w System V. Standard nazewnictwa dla tych plików konfiguracyjnych usług to service_name.conf.

Pliki zawierają zwykły tekst podzielony na różne sekcje zwane stanzas. Każda sekcja opisuje inny stan usługi i jej zachowanie. Różne sekcje kontrolują różne zdarzenia usługi. Na przykład: waiting, pre-start, start, pre-stop, stopping itp.

Sekcja (stanza) zawiera polecenia powłoki, co umożliwia inicjowanie kilku akcji dla każdego zdarzenia dla każdej usługi. Ponadto każdy plik konfiguracyjny usługi określa dwie następujące rzeczy:

• Na których poziomach uruchomienia (runlevels) usługa powinna być uruchamiana i zatrzymywana.
• Czy usługa powinna zostać zrestartowana (respawn), jeśli ulegnie awarii.

Struktura katalogów Upstart

Pliki konfiguracyjne usług Upstart znajdują się w katalogu /etc/init . Nie należy mylić go z  /etc/init.d.

Przykład Upstart

W tym przykładzie zobaczymy, jak Upstart obsługuje usługę podczas uruchamiania systemu oraz w przypadku awarii. Przejdziemy do bardziej szczegółowego wyjaśnienia praktycznych przykładów pokazanych w pierwszej części tego samouczka.

Krok 1: Zaloguj się na serwer Ubuntu 14.0.4

Po pierwsze, do przetestowania Upstart użyjemy drugiego VPS, tego z systemem Ubuntu 14.0.4. Dzieje się tak, ponieważ ta dystrybucja Linuksa implementuje Upstart natywnie. Użyj ssh lub putty, jeśli pracujesz na systemie Windows. Musisz zalogować się jako użytkownik z uprawnieniami root lub sudo. Mam użytkownika o nazwie hackins, więc zalogowałbym się w następujący sposób:

Zastąp swoim użytkownikiem root/sudo i publicznym adresem IP serwera. Następnie  naciśnij enter i podaj hasło lub frazę przejścia.

Krok 2: Zbadaj katalogi init i rc

Pliki konfiguracyjne Upstart są przechowywane w katalogu /etc/init. Jest to katalog, którego będziesz używać podczas tworzenia nowych plików konfiguracyjnych usług.

Aby wyświetlić listę nazw plików konfiguracyjnych w katalogu /etc/init, wykonaj następujące polecenie:

Jak zobaczysz w wyniku powyższego polecenia, wiele usług działa pod kontrolą Upstart. Naciśnij Q, aby wyjść z programu less.

Jeśli uruchomisz poniższe polecenie, aby wyświetlić listę plików konfiguracyjnych usług dla System V w katalogu rc, zobaczysz tylko kilka:

Krok 3: Zbadaj plik Upstart

W pierwszej części tego samouczka użyliśmy pliku mysql.conf , aby dowiedzieć się o konfiguracji serwera. Aby poszerzyć naszą wiedzę, użyjmy innej konfiguracji. Plik konfiguracyjny cron jest dobrym kandydatem. Wprowadź następujące polecenie, aby otworzyć plik:

Powinieneś otrzymać wynik podobny do poniższego zrzutu ekranu:

Skrypt jest dość prosty. Zwróć uwagę na następujące ważne pola: start on, stop on, fork oraz respawn. Zdefiniujmy, co robią te dyrektywy:

• start on nakazuje systemowi Ubuntu uruchomienie demona cron , gdy system wchodzi na poziomy uruchomienia (runlevels) 2, 3, 4 lub 5. Nie zostanie on uruchomiony na innych poziomach uruchomienia, które nie zostały tutaj określone, tj. 0, 1 lub 6.
• stop on nakazuje systemowi Ubuntu zatrzymanie działającego demona. Jednak w tym przypadku występuje wykrzyknik (!), który jest znakiem negacji. Skrypt nie powinien być zatrzymywany na poziomach uruchomienia następujących po wykrzykniku: 2,3,4,5.
• fork nakazuje Upstart odłączenie procesu od konsoli i pozostawienie go działającego w tle.
• respawn nakazuje systemowi automatyczne uruchomienie cron , jeśli ulegnie on awarii z jakiegokolwiek powodu.

Naciśnij Ctrl X, aby wyjść z edytora bez wpisywania czegokolwiek.

Inne pliki konfiguracyjne upstart mają tę samą strukturę, z sekcjami (stanzas) dla start, stop i respawn. Niektóre pliki konfiguracyjne mogą mieć dodatkowe bloki skryptów dla pre-start, pre-stop, post-start i innych. Te bloki kodu mówią systemowi, co ma wykonać, gdy proces znajduje się w którymkolwiek ze zdefiniowanych stanów.

Krok 4: Przetestuj zachowanie usługi MySQL podczas uruchamiania po rozruchu systemu

MySQL jest domyślnie ustawiony na automatyczne uruchamianie po starcie systemu. Spróbujemy go wyłączyć i zobaczyć, jak się zachowa. W Upstart usługę można wyłączyć, tworząc plik o nazwie service_name.override w katalogu /etc/init/. Zawartość tego pliku to tylko jedno słowo: manual.

Zobaczmy, jak możemy użyć tego polecenia, aby wyłączyć usługę MySQL. Wprowadź następujące polecenie, aby otworzyć plik w edytorze nano:

W otwartym pliku dodaj następującą linię:

Zapisz zmiany, naciskając Ctrl + O, a następnie Enter. Wyjdź z edytora, naciskając Ctrl + X. Uruchom następujące polecenie, aby zrestartować serwer:

Odczekaj kilka minut, a następnie zaloguj się ponownie. Po ponownym zalogowaniu sprawdź status usługi MySQL, wprowadzając następujące polecenie:

Wynik wskaże, że usługa nie jest uruchomiona:

To wskazuje, że MySQL nie uruchomił się automatycznie po starcie systemu. Następnie otwórz plik konfiguracyjny MySQL i sprawdź, czy dyrektywa start uległa zmianie:

Wynik wskaże, że nic nie zostało zmienione:

Oznacza to, że jeśli Twoja usługa nie uruchamia się automatycznie, a sprawdzasz tylko plik konfiguracyjny usługi (service_name.conf), możesz nie znaleźć błędu. Należy również sprawdzić istnienie pliku service_name.override w tym katalogu.

Wprowadź następujące polecenie, aby usunąć plik nadpisania i ponownie włączyć usługę MySQL. Następnie zrestartuj serwer:

Po uruchomieniu serwera ponownie sprawdź status usługi MySQL:

Powinno to wykazać, że usługa MySQL uruchomiła się automatycznie.

Krok 5: Przetestowanie zachowania usługi MySQL podczas uruchamiania po awarii systemu

Domyślnie usługa MySQL restartuje się automatycznie w przypadku awarii. Aby zatrzymać to zachowanie, zmodyfikujemy plik mysql.conf . Wprowadź następujące polecenie, aby otworzyć plik w edytorze nano:

Znajdź linie z dyrektywą respawn i zakomentuj je, jak pokazano poniżej za pomocą #:

Wykonaj następujące polecenia, aby zrestartować usługę:

Użyliśmy powyższych poleceń do zatrzymania i uruchomienia usługi, ponieważ użycie initctl restart lub initctl reload tutaj nie zadziała. Po uruchomieniu polecenia startu usługi MySQL, wynik wyświetli identyfikator PID dla MySQL, na przykład:

Nasz PID to 1439. Następnie zanotuj to, co otrzymałeś po uruchomieniu polecenia, użyjemy tego w następnym kroku. Aby zasymulować awarię, zabij proces MySQL za pomocą następującego polecenia, pamiętając o zastąpieniu PID zgodnie z powyższym wyjaśnieniem:

Aby sprawdzić, czy MySQL zrestartował się po awarii, odczekaj kilka minut, a następnie wprowadź następujące polecenie:

Wynik wskaże, że MySQL jest zatrzymany:

Spróbuj sprawdzić status jeszcze kilka razy, aby zobaczyć, czy nastąpiła jakaś zmiana. Zauważysz, że MySQL pozostaje zatrzymany. Dzieje się tak, ponieważ plik konfiguracyjny usługi nie zawiera dyrektyw respawn (tych, które zakomentowaliśmy). Zapoznaj się z częścią 1 tego samouczka, aby uzyskać więcej wyjaśnień na temat dyrektywy respawn.

Dlaczego pokazaliśmy Ci, jak wyłączyć automatyczny restart usług po uruchomieniu systemu lub awarii? Służy to głównie celom diagnostycznym. Jeśli na przykład Twoja usługa uruchamia się i ciągle ulega awarii, możesz chcieć ją wyłączyć, aby móc rozwiązać problem, a także zachować stabilność systemu. Możesz również zapobiec automatycznemu restartowaniu niektórych starych konfiguracji usług, jeśli uaktualnisz system do nowej dystrybucji Linuksa, która natywnie zawiera systemd omówiony w następnej sekcji.

Wprowadzenie do Systemd

Systemd to najnowszy system inicjalizacji (init), znajdujący się w najnowszych dystrybucjach Linuksa. Zawiera wiele komponentów, które składają się na nowoczesny system Linux.

Systemd zarządza nie tylko usługami, ale także całym systemem Linux. W tej sekcji skupimy się na tym, jak systemd kontroluje zachowanie usług po uruchomieniu systemu lub awarii.

Systemd jest wstecznie kompatybilny ze skryptami i poleceniami inicjującymi System V. Dlatego też, jeśli masz jakiekolwiek usługi skonfigurowane dla System V, będą one również działać pod kontrolą Systemd. Większość poleceń administracyjnych Upstart i System V została zmodyfikowana do współpracy z Systemd. Systemd zmienia swoją nazwę na init podczas uruchamiania systemu. Plik /sbin/init istnieje i stanowi dowiązanie symboliczne do /bin/systemd.

Pliki konfiguracyjne Systemd: Pliki jednostek

Konfiguracja Systemd składa się z plików jednostek. Każdy plik jednostki reprezentuje zasób systemowy. Podczas gdy pozostałe dwa systemy inicjalizacji (tj. System V i Upstart) były odpowiedzialne za zarządzanie usługami systemu Linux, Systemd zarządza nie tylko demonami usług, ale także innymi rodzajami zasobów systemowych, takimi jak ścieżki systemu operacyjnego urządzeń, gniazda, punkty montowania itp. Pliki jednostek przechowują informacje o zasobie.

Każdy plik jednostki reprezentuje określony zasób systemowy o schemacie nazewnictwa service_name.unit_type. Oznacza to, że znajdziesz pliki takie jak home.mount, dbus.service, sshd.socket itp. Pliki jednostek to proste pliki tekstowe o deklaratywnej składni, która jest łatwa do zrozumienia i modyfikacji.

Struktura katalogów

Główną lokalizacją natywnych plików jednostek jest katalog /lib/systemd/system/. Pliki jednostek utworzone przez Ciebie lub niestandardowo utworzone przez administratorów systemu, a także inne zmodyfikowane natywne pliki jednostek są przechowywane w katalogu /etc/systemd/system.

Jeśli plik jednostki o tej samej nazwie istnieje zarówno w /lib/systemd/system/, jak i /etc/systemd/system, systemd użyje tego znajdującego się w katalogu /etc.

Gdy włączysz uruchamianie usługi podczas startu systemu lub na jakimkolwiek innym poziomie uruchamiania (target/runlevel), tworzone jest dowiązanie symboliczne do pliku jednostki tej usługi w odpowiednich katalogach w /etc/systemd/system. Pliki jednostek w katalogu /etc/systemd/system są tylko dowiązaniami symbolicznymi do plików o podobnej nazwie w katalogu /lib/systemd/system.

Sekwencja inicjalizacji Systemd: Jednostki docelowe

Jednostki docelowe to unikalne typy plików jednostek, zwykle z przyrostkiem .target. Jednostki docelowe różnią się od innych typów plików jednostek tym, że nie reprezentują jednego konkretnego zasobu. Zamiast tego reprezentują stan całego systemu w danym momencie.

Aby to osiągnąć, jednostki docelowe grupują i uruchamiają wiele plików jednostek, które są częścią określonego stanu. Chociaż cele (targets) Systemd i poziomy uruchamiania (runlevels) System V można luźno porównać, nie są one tym samym. Plik jednostki docelowej ma nazwę zamiast numeru. Na przykład znajdziesz coś takiego jak multi-user.target zamiast runlevel 3 lub reboot.target zamiast runlevel 6. System Linux może uruchomić się z multi-user.target. W tym przypadku zasadniczo sprowadza to serwer do poziomu uruchamiania 2, 3 lub 4, co uruchamia system w trybie tekstowym wieloużytkownikowym z włączoną siecią.

Różnica polega na sposobie doprowadzenia serwera do tego poziomu. System V uruchamia usługi sekwencyjnie. Z drugiej strony, podczas uruchamiania systemu, systemd sprawdza, czy istnieją inne usługi lub zasoby i określa kolejność ich ładowania.

Kolejną różnicą między jednostkami docelowymi systemd a poziomami uruchamiania System V jest to, że dystrybucja Linuksa korzystająca z System V będzie istnieć tylko na jednym poziomie uruchamiania. Jeśli zmodyfikujesz poziom uruchamiania, po prostu przełączy się on i będzie istniał na tym nowym poziomie. Z drugiej strony, pliki jednostek docelowych mogą się wzajemnie zawierać.  Co więcej, aktywacja jednostki docelowej zapewnia, że inne jednostki docelowe zostaną załadowane jako jej część. Na przykład, jeśli uruchomisz system Linux z graficznym interfejsem użytkownika, będzie on miał graphical.target aktywowany. To z kolei automatycznie zapewnia, że multi-user.target również zostanie załadowany i aktywowany.

Oto tabela porównująca poziomy uruchamiania i jednostki docelowe.

Poziom uruchamiania (System V)	Jednostki docelowe (systemd)
poziom uruchamiania 0	poweroff.target
poziom uruchamiania 1	rescue.target
poziom uruchamiania 2,3,4	multi-user.target
poziom uruchamiania 5	graphical.target
poziom uruchamiania 6	reboot.target

Systemd default.target

W systemd, default.target jest odpowiednikiem domyślnego poziomu uruchamiania w System V. Widzieliśmy, że domyślny poziom uruchamiania w System V był zdefiniowany w pliku inittab. W systemd mamy default.target plik. Domyślny plik docelowy jest przechowywany w katalogu /etc/systemd/system. Tworzy on dowiązanie symboliczne do jednego z plików jednostek docelowych w /lib/systemd/system. Zmiana domyślnego celu oznacza po prostu ponowne utworzenie dowiązania symbolicznego i zmodyfikowanie poziomu uruchamiania systemu.

W System V plik inittab określał, w którym katalogu Linux znajdzie skrypty init. Mógł to być dowolny z katalogów rc, jak wyjaśniono wcześniej. Z drugiej strony, domyślny cel systemd określa jednostki zasobów do załadowania podczas uruchamiania systemu. Wszystkie zdefiniowane jednostki są ładowane. Jednak nie wszystkie są ładowane równolegle i nie wszystkie są ładowane sekwencyjnie. Ładowanie jednostki zasobu zależy od innych zasobów, których ona chce lub wymaga.

Zależności systemd: Wants i Requires

W tej sekcji omówimy, jak systemd obsługuje zależności. Widzieliśmy, że w przypadku Upstart równoległe ładowanie usług jest możliwe przy użyciu plików konfiguracyjnych. Omówiliśmy również, jak System V używa poziomów uruchamiania do określenia, którą usługę uruchomić automatycznie lub poczekać, aż inna usługa lub zasób się uruchomi. Podobnie usługi systemd można skonfigurować tak, aby ładowały się w jednej lub kilku jednostkach docelowych lub czekały, aż inna usługa lub zasób się uruchomi.

W systemd plik jednostki, który wymaga innej jednostki, nie uruchomi się, dopóki wymagana jednostka nie zostanie załadowana i nie stanie się aktywna. Jeśli wymagana jednostka nie załaduje się, podczas gdy pierwsza jednostka jest aktywna, pierwsza jednostka zostanie zatrzymana.

To zachowanie zapewnia stabilność systemu. Usługa, która wymaga określonego zasobu (na przykład portu), aby był dostępny i aktywny, może w ten sposób zostać zmuszona do czekania, aż zasób będzie dostępny (tj. port zostanie otwarty).

Dla kontrastu, jednostka, która chce innej jednostki, nie nakłada takich ograniczeń. Nie zatrzyma się, jeśli pożądana jednostka zatrzyma się, podczas gdy jednostka wywołująca jest nadal aktywna. Na przykład niektóre nieistotne usługi w trybie graphical-target.

Przykład systemd

Zobaczmy, jak możemy skonfigurować zachowanie usługi w systemd.

Krok 1: Zaloguj się do swojej instancji VPS

Użyjemy MySQL jako rzeczywistej usługi oraz CentOS 7 jako serwera. Aby przejść przez te kroki w praktyce i zrozumieć pojęcia, zaloguj się do swojego VPS z CentOS 7 lub utwórz go na CloudSigma.  VPS z dystrybucją CentOS 7, Debian 7 lub 8, bądź Ubuntu 15 lub nowszą jest odpowiedni dla tej sekcji, ponieważ wszystkie one są wyposażone w systemd. Zaloguj się za pomocą polecenia ssh lub, jeśli korzystasz z systemu Windows, użyj PuTTY:

Krok 2: Zbadaj plik default.target i zależności

Sekwencja uruchamiania systemd następuje po długim łańcuchu zależności, które szczegółowo omówimy w tej sekcji.

• default.target

Plik default.target kontroluje usługi, które uruchamiają się podczas normalnego startu systemu. Możesz wyświetlić domyślny plik jednostki docelowej za pomocą następującego polecenia:

Wynik wygląda podobnie do poniższego zrzutu ekranu:

Zrzut ekranu pokazuje, że domyślny cel tworzy dowiązanie symboliczne do pliku multi-user.target w /lib/systemd/system/ katalogu. Oznacza to, że domyślnie system uruchomi się w trybie multi-user.target, co odpowiada runlevel 3.

• multi-user.target.wants

Aby zobaczyć wszystkie usługi, których wymaga plik multi-user.target, wprowadź następujące polecenie:

Wynik zawiera wiele linii, oto fragment:

Jak pokazuje wynik, są to dowiązania symboliczne wskazujące na rzeczywiste pliki jednostek w katalogu /lib/systemd/system/ katalogu. Wyróżniliśmy mysqld.service , aby pokazać, że jest ona również częścią multi-user.target. Jeśli chcesz potwierdzić, czy określona usługa jest skonfigurowana do uruchamiania, możesz zmodyfikować polecenie dla tego pliku. Na przykład możemy przefiltrować wyniki, aby znaleźć demona mysql lub cron, używając następujących poleceń:

Wynik pokaże:

Aby przefiltrować wynik dla demona cron, wprowadź następujące polecenie:

Wynik pokaże:

Oprócz multi-user.target, istnieją inne rodzaje celów, np. system-update.target lub basic.target.

Wprowadź następujące polecenie, aby zobaczyć, od jakich celów zależy multi-user target:

Wynik pokazuje:

Oznacza to, że basic-target musi załadować się jako pierwszy, aby system uruchomił się w trybie multi-user.target.

• basic-target

Wprowadź następujące polecenie, aby zobaczyć, jakich innych celów wymaga basic.target:

Wynik pokaże:

• sysinit.target

Możesz uruchomić następujące polecenie, aby sprawdzić, czy istnieją jakieś wymagane cele dla sysinit.target. Składnia polecenia jest taka sama. Możesz ją modyfikować na bieżąco, aby zobaczyć, które jednostki docelowe są wymagane przez inne jednostki docelowe. Oto polecenie:

Wynik pokaże, że nie ma wymaganych jednostek dla sysinit.target. Możemy sprawdzić, czy istnieją inne usługi i cele pożądane przez sysinit.target za pomocą następującego polecenia:

Wynik pokazuje długą listę usług i celów pożądanych przez sysinit.target. Część wyniku można zobaczyć poniżej:

Podczas inicjalizacji systemu za pomocą system4, system nie pozostaje tylko w jednym celu. Zamiast tego ładuje usługi w sposób zależny, przechodząc z jednego celu do drugiego.

Krok 3: Zbadanie pliku jednostki

Zobaczmy, jak wygląda plik jednostki. W pierwszej części tego samouczka użyliśmy pliku jednostki usługi MySQL i użyjemy go ponownie. Możemy jednak również przyjrzeć się innemu plikowi jednostki usługi – plikowi jednostki sshd. Wprowadź następujące polecenie, aby otworzyć plik konfiguracyjny sshd:

Poniżej znajduje się zrzut ekranu przedstawiający linie w pliku:

Jak widać, bloki kodu wyróżnione w pliku ułatwiają jego zrozumienie i modyfikację w razie potrzeby. Poniżej znajduje się kilka ważnych dyrektyw, które warto zrozumieć:

• After – After klauzula informuje system, aby ładował usługę dopiero po załadowaniu określonych celów i usług. W tym przypadku usługa SSHD zostanie załadowana po załadowaniu celu sieciowego i usługi keygen.
• Wants – Wants klauzula wskazuje, które cele pożądają tej usługi. W tym przypadku ssh-keygen.service pożąda sshd.service. Jeśli jednak sshd ulegnie awarii lub się zawiesi, nie spowoduje to wyłączenia ssh-keygen.service.

Naciśnij Ctrl + X, aby zamknąć edytor.

Krok 4: Przetestowanie zachowania usługi MySQL podczas uruchamiania systemu

W tej sekcji pokażemy, jak można zmienić i przetestować zachowanie usługi MySQL podczas uruchamiania systemu. W poprzedniej sekcji widzieliśmy, że mysqld.service jest pożądana przez multi-user.target. W związku z tym uruchomi się automatycznie podczas startu systemu.

Możesz wyłączyć usługę, uruchamiając następujące polecenie:

Uruchomienie polecenia pokazuje, że dowiązanie symboliczne mysql zostało usunięte z katalogu /etc/systemd/system/multi-user.target.wants/ . Aby to przetestować, uruchom następujące polecenie, aby sprawdzić, czy MySQL jest nadal pożądany przez multi-user.target:

Polecenie nic nie zwraca. Jeśli spróbujesz zrestartować serwer i sprawdzić status MySQL, nie będzie on uruchomiony, co oznacza, że nie uruchomił się automatycznie podczas startu systemu.

Teraz włącz ponownie usługę za pomocą polecenia:

Wynik pokaże dowiązanie symboliczne (symlink). Jeśli zrestartujesz serwer, MySQL powinien uruchomić się automatycznie. Włączenie usługi Systemd tworzy dowiązanie symboliczne w katalogu wants domyślnego celu (target). Wyłączenie usługi Systemd usuwa dowiązanie symboliczne z wants katalogu.

Krok 5: Testowanie zachowania usługi MySQL po awarii usługi

Domyślnie usługa MySQL uruchomi się automatycznie w przypadku awarii. Możemy wyłączyć to zachowanie w pliku konfiguracyjnym Systemd dla MySQL. Najpierw przyjrzyjmy się temu plikowi. Wprowadź następujące polecenie, aby otworzyć plik:

Poniższy zrzut ekranu przedstawia wynik:

Wartość dyrektywy Restart jest ustawiona na on-failure. Oznacza to, że usługa MySQL zostanie zrestartowana po nieprawidłowych kodach wyjścia, limicie czasu (timeout) lub nieprawidłowych sygnałach. Poniżej znajduje się tabela przedstawiająca niektóre parametry restartu ze strony man.

Ustawienia restartu/Przyczyny wyjścia	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
Prawidłowy kod wyjścia lub sygnał		X	X
Nieprawidłowy kod wyjścia		X		X
Nieprawidłowy sygnał		X		X	X	X
Limit czasu		X		X	X
Watchdog		X		X	X		X

Dwiema ważnymi dyrektywami w pliku jednostki Systemd są Restart oraz RestartSec. Kontrolują one zachowanie usługi po awarii. Restart określa, kiedy usługa powinna się zrestartować, a RestartSec określa, jak długo powinna czekać przed ponownym uruchomieniem po awarii. Aby wyłączyć zachowanie restartu, zakomentuj dyrektywę Restart, dodając znak # na początku linii, jak pokazano poniżej:

Teraz przeładuj demona systemowego, a następnie przeładuj usługę mysqld za pomocą następujących poleceń:

Następnie uruchom następujące polecenie, aby znaleźć główny identyfikator PID (Main PID) usługi MySQL:

Główny PID w naszym teście to 23809. Zanotuj swój, aby użyć go w następnym poleceniu. Używając polecenia kill -9, zasymuluj awarię, zabijając proces. Pamiętaj również, aby zastąpić go numerem procesu otrzymanym w swoim teście:

Jeśli uruchomisz polecenie sprawdzające status MySQL, zobaczysz, że nie jest on aktywny i nie udało się go zrestartować:

Pozostanie w stanie błędu (failed) tak długo, jak dyrektywa Restart będzie zakomentowana w pliku konfiguracyjnym mysqld.service. Emuluje to awarię, w której usługa zatrzymuje się i nie uruchamia się ponownie.

Aby ponownie włączyć usługę, możesz edytować plik konfiguracyjny mysqld.service, odkomentować dyrektywę Restart, a następnie zapisać i zamknąć plik. Tak jak wcześniej, przeładuj demona i zrestartuj usługę. Przywróci to usługę do jej początkowej konfiguracji i teraz będzie mogła automatycznie uruchamiać się po awarii. To już wszystko, jeśli chodzi o konfigurację usługi do automatycznego uruchamiania po awarii. Jeśli chcesz skonfigurować usługi tak, aby uruchamiały się automatycznie po awarii, wystarczy dodać dyrektywę Restart (i jeśli chcesz, możesz również dodać dyrektywę RestartSec) w sekcji [Service] pliku jednostki usługi.

Podsumowanie

W tym samouczku omówiliśmy, jak Linux radzi sobie z usługami podczas uruchamiania lub po awarii. Aby zrozumieć proces inicjalizacji systemu Linux, omówiliśmy trzy systemy init używane przez Linuksa: System V, Upstart i Systemd. Omówiliśmy ich ewolucję oraz to, jak każdy proces init działa w odniesieniu do automatycznego uruchamiania usługi po restarcie systemu lub awarii.

Ponieważ zarówno demony init, jak i dystrybucje Linuksa ewoluowały na przestrzeni czasu, pamiętaj o sprawdzeniu wersji używanej dystrybucji Linuksa, aby wiedzieć, który demon init jest natywnie obsługiwany przez Twój system.

Natywne aplikacje systemu Linux oraz większość aplikacji innych firm uruchamiają się automatycznie po rozruchu lub awarii systemu, więc nie musisz nic robić. Wiedza zawarta w tym samouczku jest kluczowa podczas konfigurowania zachowania przy uruchamianiu i ponownym uruchamianiu (respawn) własnych niestandardowych usług lub podczas rozwiązywania problemów z usługami, które stale ulegają awarii.

Miłego korzystania z komputera!