Wyszukiwanie w witrynie

LFCS: Zarządzanie procesem i usługami uruchamiania systemu (SysVinit, Systemd i Upstart) - część 7


Kilka miesięcy temu Linux Foundation ogłosiła uzyskanie certyfikatu LFCS (Linux Foundation Certified Sysadmin), nowego, ekscytującego programu, którego celem jest umożliwienie osobom z całego świata zdobądź certyfikat w wykonywaniu podstawowych i średnio zaawansowanych zadań administracyjnych w systemach Linux. Obejmuje to wspieranie już działających systemów i usług, a także wyszukiwanie i analizę problemów z pierwszej ręki, a także możliwość decydowania, kiedy zgłosić problemy zespołom inżynierskim.

Poniższy film przedstawia krótkie wprowadzenie do programu certyfikacyjnego Linux Foundation.

Ten post jest częścią 7 z serii 10 samouczków. W tej części wyjaśnimy, jak zarządzać procesem uruchamiania systemu Linux i usługami wymaganymi do egzaminu certyfikacyjnego LFCS.

Zarządzanie procesem uruchamiania systemu Linux

Proces uruchamiania systemu Linux składa się z kilku faz, z których każda jest reprezentowana przez inny komponent. Poniższy diagram krótko podsumowuje proces rozruchu i pokazuje wszystkie główne komponenty, których to dotyczy.

Po naciśnięciu przycisku Zasilanie na komputerze oprogramowanie sprzętowe zapisane w chipie EEPROM na płycie głównej inicjuje proces POST ( Autotest po włączeniu zasilania), aby sprawdzić stan zasobów sprzętowych systemu. Po zakończeniu POST oprogramowanie sprzętowe wyszukuje i ładuje moduł ładujący pierwszego stopnia, znajdujący się w MBR lub w EFI partycję pierwszego dostępnego dysku i przekazuje mu kontrolę.

Metoda MBR

Plik MBR znajduje się w pierwszym sektorze dysku oznaczonym w ustawieniach BIOS jako startowy i ma rozmiar 512 bajtów.

  1. Pierwsze 446 bajtów: program ładujący zawiera zarówno kod wykonywalny, jak i tekst komunikatu o błędzie.
  2. Następne 64 bajty: Tabela partycji zawiera rekordy dla każdej z czterech partycji (podstawowej lub rozszerzonej). Między innymi każdy rekord wskazuje status (aktywny/nieaktywny), rozmiar oraz sektory początkowe/końcowe każdej partycji.
  3. Ostatnie 2 bajty: liczba magiczna służy do sprawdzania poprawności rekordu MBR.

Poniższe polecenie wykonuje kopię zapasową MBR (w tym przykładzie /dev/sda jest pierwszym dyskiem twardym). Powstały plik mbr.bkp może się przydać w przypadku uszkodzenia tablicy partycji, na przykład uniemożliwiającej uruchomienie systemu.

Oczywiście, aby móc z niego później skorzystać, jeśli zajdzie taka potrzeba, będziemy musieli go zapisać i przechowywać w innym miejscu (na przykład na dysku USB). Plik ten pomoże nam przywrócić MBR i umożliwi nam ponowne działanie wtedy i tylko wtedy, gdy w międzyczasie nie zmienimy układu dysku twardego.

Kopia zapasowa MBR
dd if=/dev/sda of=mbr.bkp bs=512 count=1

Przywracanie MBR
dd if=mbr.bkp of=/dev/sda bs=512 count=1

Metoda EFI/UEFI

W przypadku systemów korzystających z metody EFI/UEFI oprogramowanie sprzętowe UEFI odczytuje swoje ustawienia, aby określić, która aplikacja UEFI ma zostać uruchomiona i skąd (tj. na jakim dysku i partycji zlokalizowana jest partycja EFI).

Następnie ładowany i uruchamiany jest moduł ładujący drugiego etapu (inaczej menedżer rozruchu). GRUB [GRand Unified Boot] to najczęściej używany menedżer rozruchu w systemie Linux. W większości obecnie używanych systemów można znaleźć jedną z dwóch różnych wersji.

  1. Starszy plik konfiguracyjny GRUB: /boot/grub/menu.lst (starsze dystrybucje, nie są obsługiwane przez oprogramowanie układowe EFI/UEFI).
  2. Plik konfiguracyjny GRUB2: najprawdopodobniej /etc/default/grub.

Chociaż cele egzaminu LFCS nie wymagają wyraźnie wiedzy na temat wewnętrznych elementów GRUB, jeśli jesteś odważny i możesz sobie pozwolić na zepsucie swojego systemu (możesz spróbować najpierw na maszynie wirtualnej, na wszelki wypadek), musisz uruchomić.

update-grub

Jako root po zmodyfikowaniu konfiguracji GRUB-a w celu zastosowania zmian.

Zasadniczo GRUB ładuje domyślne jądro i obraz initrd lub initramfs. Krótko mówiąc, initrd lub initramfs pomagają w wykryciu sprzętu, załadowaniu modułu jądra i wykryciu urządzenia niezbędnego do zamontowania prawdziwego głównego systemu plików.

Po uruchomieniu prawdziwego głównego systemu plików jądro uruchamia menedżera systemu i usług (init lub systemd, którego identyfikacja procesu lub PID ma zawsze wartość 1), aby rozpocząć normalne działanie użytkownika proces rozruchu kosmicznego w celu zaprezentowania interfejsu użytkownika.

Zarówno init, jak i systemd są demonami (procesami w tle), które zarządzają innymi demonami, jako pierwsza usługa uruchamiana (podczas rozruchu) i ostatnia usługa kończąca się (podczas zamykania).

Uruchamianie usług (SysVinit)

Koncepcja poziomów działania w systemie Linux określa różne sposoby korzystania z systemu poprzez kontrolowanie uruchomionych usług. Innymi słowy, poziom działania kontroluje, jakie zadania można wykonać w bieżącym stanie wykonania=poziom działania (a które nie mogą).

Tradycyjnie ten proces uruchamiania był wykonywany w oparciu o konwencje zapoczątkowane w Systemie V UNIX, gdzie system przekazywał wykonywanie kolekcji skryptów, które uruchamiają i zatrzymują usługi, gdy komputer wchodzi na określony poziom pracy (który, innymi słowy, , to inny tryb pracy systemu).

Na każdym poziomie działania poszczególne usługi można ustawić tak, aby były uruchamiane lub wyłączane, jeśli działają. Najnowsze wersje niektórych głównych dystrybucji odchodzą od standardu System V na rzecz raczej nowego menedżera usług i systemu o nazwie systemd (co oznacza demona systemowego), ale zwykle obsługuje polecenia sysv ze względu na kompatybilność. Oznacza to, że można uruchomić większość dobrze znanych narzędzi inicjujących sysv w dystrybucji systemowej.

Przeczytaj także: Dlaczego „systemd” zastępuje „init” w systemie Linux

Oprócz uruchomienia procesu systemowego, init sprawdza plik /etc/inittab, aby zdecydować, jaki poziom działania należy wprowadzić.

Runlevel

Opis

0

Zatrzymaj system. Poziom pracy 0 to specjalny stan przejściowy używany do szybkiego zamykania systemu.

1

Nazywany także s lub S, ten poziom pracy jest czasami nazywany trybem konserwacji. To, jakie usługi, jeśli w ogóle, są uruchamiane na tym poziomie działania, zależy od dystrybucji. Zwykle jest używany do niskopoziomowej konserwacji systemu, która może zostać zakłócona przez normalne działanie systemu.

2

Wielu użytkowników. W systemach Debiana i jego pochodnych jest to domyślny poziom działania, obejmujący - jeśli jest dostępny - graficzny login. W systemach opartych na Red-Hat jest to tryb wielu użytkowników bez połączenia sieciowego.

3

W systemach opartych na Red-Hat jest to domyślny tryb wielu użytkowników, w którym uruchamiane jest wszystko oprócz środowiska graficznego. Ten poziom działania oraz poziomy 4 i 5 zwykle nie są używane w systemach opartych na Debianie.

4

Zwykle domyślnie nieużywane i dlatego dostępne do dostosowania.

5

W systemach opartych na Red-Hat, pełny tryb wielu użytkowników z logowaniem GUI. Ten poziom działania jest podobny do poziomu 3, ale z dostępnym logowaniem GUI.

6

Uruchom ponownie system.

Aby przełączać się między poziomami pracy, możemy po prostu zmienić poziom pracy za pomocą polecenia init: init N (gdzie N jest jednym z poziomów pracy wymienionych powyżej). Należy pamiętać, że nie jest to zalecany sposób przenoszenia działającego systemu na inny poziom działania, ponieważ nie powoduje to ostrzeżenia dla istniejących zalogowanych użytkowników (w ten sposób powodując utratę pracy i nieprawidłowe zakończenie procesów).

Zamiast tego należy użyć polecenia shutdown w celu ponownego uruchomienia systemu (co najpierw wysyła komunikat ostrzegawczy do wszystkich zalogowanych użytkowników i blokuje dalsze logowania, a następnie sygnalizuje init zmianę poziomów pracy); jednakże domyślny poziom pracy (ten, na którym będzie uruchamiany system) musi być najpierw edytowany w pliku /etc/inittab.

Z tego powodu wykonaj poniższe kroki, aby prawidłowo przełączać poziomy działania. Jako root poszukaj następującego wiersza w pliku /etc/inittab.

id:2:initdefault:

i zmień liczbę 2 dla żądanego poziomu działania za pomocą preferowanego edytora tekstu, takiego jak vim (opisanego w Jak używać edytora vi/vim w systemie Linux – część 2 tej serii).

Następnie uruchom jako root.

shutdown -r now

To ostatnie polecenie zrestartuje system, powodując jego uruchomienie na określonym poziomie działania podczas następnego rozruchu i uruchomi skrypty znajdujące się w /etc/rc[runlevel].d katalogu, aby zdecydować, które usługi należy uruchomić, a które nie. Na przykład dla poziomu działania 2 w następującym systemie.

Zarządzaj usługami za pomocą polecenia chkconfig

Aby włączyć lub wyłączyć usługi systemowe podczas rozruchu, użyjemy polecenia chkconfig w CentOS/openSUSE i sysv-rc-conf w Debianie i jego pochodnych. To narzędzie może nam również pokazać, jaki jest wstępnie skonfigurowany stan usługi dla określonego poziomu działania.

Przeczytaj także: Jak zatrzymać i wyłączyć niechciane usługi w systemie Linux

Wyświetlanie konfiguracji poziomu działania usługi.

chkconfig --list [service name]
chkconfig --list postfix
chkconfig --list mysqld

Na powyższym obrazku widać, że postfix jest uruchamiany, gdy system wejdzie na poziomy działania od 2 do 5, podczas gdy mysqld b> będzie domyślnie uruchamiany na poziomach działania od 2 do 4. Załóżmy teraz, że nie jest to oczekiwane zachowanie.

Na przykład musimy włączyć mysqld również dla poziomów pracy 5 i wyłączyć postfix dla poziomów pracy 4 i 5. Oto, co zrobilibyśmy w każdym przypadku (uruchom wykonując polecenia jako root).

Włączanie usługi dla określonego poziomu działania
chkconfig --level [level(s)] service on
chkconfig --level 5 mysqld on
Wyłączanie usługi dla poszczególnych poziomów działania
chkconfig --level [level(s)] service off
chkconfig --level 45 postfix off

Teraz będziemy wykonywać podobne zadania w systemie opartym na Debianie przy użyciu sysv-rc-conf.

Zarządzaj usługami za pomocą sysv-rc-conf

Skonfigurowanie usługi tak, aby uruchamiała się automatycznie na określonym poziomie działania i uniemożliwiała jej uruchamianie na wszystkich pozostałych.

1. Użyjmy następującego polecenia, aby zobaczyć, na jakich poziomach działania skonfigurowano uruchamianie mdadm.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

2. Użyjemy sysv-rc-conf, aby zapobiec uruchamianiu mdadm na wszystkich poziomach działania z wyjątkiem 2. Po prostu zaznacz lub usuń zaznaczenie (za pomocą spacji) zgodnie z potrzebami (możesz poruszać się w górę, w dół, w lewo i w prawo za pomocą klawiszy strzałek).

sysv-rc-conf

Następnie naciśnij q, aby zakończyć.

3. Zrestartujemy system i ponownie uruchomimy polecenie z KROKU 1.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

Na powyższym obrazku widać, że mdadm jest skonfigurowany tak, aby uruchamiał się tylko na poziomie działania 2.

A co z systemdem?

systemd to kolejny menedżer usług i systemów, który jest wdrażany w kilku głównych dystrybucjach Linuksa. Ma na celu umożliwienie równoległego wykonywania większej liczby procesów podczas uruchamiania systemu (w przeciwieństwie do sysvinit, który zawsze jest wolniejszy, ponieważ uruchamia procesy pojedynczo, sprawdza, czy jeden jest zależny od drugiego i czeka na demony do uruchomienia, aby można było uruchomić więcej usług) i służyć jako dynamiczne zarządzanie zasobami działającego systemu.

W ten sposób usługi są uruchamiane w razie potrzeby (aby uniknąć zużywania zasobów systemowych), a nie uruchamiane bez uzasadnionego powodu podczas rozruchu.

Przeglądając status wszystkich procesów uruchomionych w systemie, zarówno usług natywnych systemd, jak i usług SysV, uruchom następującą komendę.

systemctl

Kolumna LOAD pokazuje, czy definicja jednostki (patrz kolumna UNIT, która pokazuje usługę lub cokolwiek obsługiwanego przez systemd) została poprawnie załadowana, natomiast kolumna ACTIVE< Kolumny i SUB pokazują aktualny stan takiej jednostki.

Wyświetlanie informacji o aktualnym statusie usługi

Gdy kolumna AKTYWNY wskazuje, że jednostka ma status inny niż aktywny, możemy sprawdzić, co się stało za pomocą.

systemctl status [unit]

Na przykład na powyższym obrazku plik media-samba.mount znajduje się w stanie awarii. Biegnijmy.

systemctl status media-samba.mount

Widzimy, że plik media-samba.mount nie powiódł się, ponieważ proces montowania na hoście dev1 nie był w stanie znaleźć udziału sieciowego pod adresem //192.168.0.10/gacanepa.

Uruchamianie lub zatrzymywanie usług

Gdy udział sieciowy //192.168.0.10/gacanepa stanie się dostępny, spróbujmy uruchomić, następnie zatrzymać i na koniec ponownie uruchomić urządzenie media-samba.mount. Po wykonaniu każdej akcji uruchommy systemctl status media-samba.mount, aby sprawdzić jego status.

systemctl start media-samba.mount
systemctl status media-samba.mount
systemctl stop media-samba.mount
systemctl restart media-samba.mount
systemctl status media-samba.mount

Włączanie lub wyłączanie uruchamiania usługi podczas rozruchu

W obszarze systemd możesz włączyć lub wyłączyć usługę podczas jej uruchamiania.

systemctl enable [service] 		# enable a service 
systemctl disable [service] 		# prevent a service from starting at boot

Proces włączania lub wyłączania automatycznego uruchamiania usługi przy starcie polega na dodaniu lub usunięciu dowiązań symbolicznych w katalogu /etc/systemd/system/multi-user.target.wants.

Alternatywnie możesz sprawdzić aktualny stan usługi (włączona lub wyłączona) za pomocą polecenia.

systemctl is-enabled [service]

Na przykład,

systemctl is-enabled postfix.service

Ponadto możesz ponownie uruchomić lub zamknąć system za pomocą.

systemctl reboot
systemctl shutdown

Dorobkiewicz

Upstart jest opartym na zdarzeniach zamiennikiem demona /sbin/init i powstał z potrzeby uruchamiania usług tylko wtedy, gdy są potrzebne (również nadzorowania ich podczas są uruchomione) i obsługiwać zdarzenia w momencie ich wystąpienia, przewyższając w ten sposób klasyczny, oparty na zależnościach system sysvinit.

Został pierwotnie opracowany dla dystrybucji Ubuntu, ale jest używany w Red Hat Enterprise Linux 6.0. Chociaż miał nadawać się do wdrożenia we wszystkich dystrybucjach Linuksa jako zamiennik sysvinit, z czasem został przyćmiony przez systemd. 14 lutego 2014 r. Mark Shuttleworth (założyciel Canonical Ltd.) ogłosił, że przyszłe wydania Ubuntu będą używać systemd jako domyślnego demona inicjującego.

Ponieważ skrypt startowy SysV dla systemu był tak powszechny od dawna, duża liczba pakietów oprogramowania zawiera skrypty startowe SysV. Aby uwzględnić takie pakiety, Upstart zapewnia tryb zgodności: uruchamia skrypty startowe SysV w zwykłych lokalizacjach (/etc/rc.d/rc?.d, /etc/init.d/ rc?.d, /etc/rc?.d lub podobną lokalizację). Zatem, jeśli zainstalujemy pakiet, który nie zawiera jeszcze skryptu konfiguracyjnego Upstart, powinien on mimo to uruchomić się w zwykły sposób.

Co więcej, jeśli mamy zainstalowane narzędzia takie jak chkconfig, powinieneś móc ich używać do zarządzania usługami opartymi na SysV, tak samo jak w przypadku systemów opartych na sysvinit.

Skrypty Upstart obsługują także uruchamianie i zatrzymywanie usług w oparciu o szerszą gamę działań niż skrypty startowe SysV; na przykład Upstart może uruchomić usługę za każdym razem, gdy podłączone jest określone urządzenie sprzętowe.

System korzystający wyłącznie z Upstart i jego natywnych skryptów zastępuje plik /etc/inittab i specyficzne dla poziomu działania katalogi skryptów startowych SysV plikiem .conf skrypty w katalogu /etc/init.

Te skrypty *.conf (znane również jako definicje zadań) zazwyczaj składają się z następujących elementów:

    1. Opis procesu.
    2. Poziomy działania, na których powinien działać proces, lub zdarzenia, które powinny go uruchomić.
    3. Poziomy działania, na których proces powinien zostać zatrzymany, lub zdarzenia, które powinny go zatrzymać.
    4. Opcje.
    5. Polecenie uruchomienia procesu.

Na przykład,

My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email >"
Stanzas

#
Stanzas define when and how a process is started and stopped
See a list of stanzas here: http://upstart.ubuntu.com/wiki/Stanzas#respawn
When to start the service
start on runlevel [2345]
When to stop the service
stop on runlevel [016]
Automatically restart process in case of crash
respawn
Specify working directory
chdir /home/dave/myfiles
Specify the process/command (add arguments if needed) to run
exec bash backup.sh arg1 arg2

Aby zastosować zmiany, musisz poinformować Upstart o ponownym załadowaniu konfiguracji.

initctl reload-configuration

Następnie rozpocznij zadanie, wpisując następujące polecenie.

sudo start yourjobname

Gdzie nazwa_zadania to nazwa zadania dodanego wcześniej za pomocą skryptu nazwa_zadania.conf.

Pełniejszy i bardziej szczegółowy przewodnik informacyjny dotyczący Upstart jest dostępny na stronie internetowej projektu w menu „Książka kucharska”.

Streszczenie

Znajomość procesu uruchamiania systemu Linux jest konieczna, aby pomóc Ci w rozwiązywaniu problemów, a także dostosowaniu wydajności komputera i uruchomionych usług do Twoich potrzeb.

W tym artykule przeanalizowaliśmy, co dzieje się od momentu naciśnięcia przełącznika Zasilania w celu włączenia urządzenia, aż do uzyskania w pełni działającego interfejsu użytkownika. Mam nadzieję, że nauczyłeś się czytać go tak samo jak ja, składając go w całość. Zachęcamy do pozostawienia komentarzy lub pytań poniżej. Zawsze czekamy na kontakt od naszych czytelników!