Głęboki wgląd w system „Ubuntu Linux” – czy to widzimy?

LINUX, jak wiemy, jest jądrem, a nie systemem operacyjnym, jest dostępny w kilku dystrybucjach, takich jak: Debian, Fedora, Ubuntu mocny> itp. i wiele innych. System operacyjny Ubuntu opracowany przez Marka Shuttlewortha jest powszechnie znany i powszechnie używany przez wielu. Ponadto, ponieważ jest darmowy i ma otwarte oprogramowanie, co roku wydawana jest jego nowa wersja, do której przyczyniają się tysiące programistów, którzy przyczyniają się do jego rozwoju. Ale jak to działa? Jakie wszystkie procesy, lista zdarzeń sprawiają, że to działa i jakie jest znaczenie tych procesów?

Ten artykuł zabierze Cię nieco głębiej w wewnętrzne elementy Ubuntu OS, które są bardzo interesujące i pomogą nowicjuszowi w pełnym zrozumieniu jego funkcjonowania.

Złóż system

Linux ma proces swojego funkcjonowania, każda usługa systemowa, w tym zarządzanie energią, uruchamianie systemu, obsługa awarii systemu, to proces, który ma plik konfiguracyjny w „/etc/init” opisujący zdarzenie, w którym wykona i odpowiednie zdarzenie, po którym zatrzyma swoje wykonanie, wraz z tym, że przechowuje także inne pliki konfiguracyjne opisujące jego zachowanie w czasie wykonywania w systemowym katalogu „/etc/”, dzięki czemu system napędzany wydarzeniem.

Jeśli generowane są zdarzenia, ktoś powinien tam być, aby je złapać i wykonać? Oczywiście kontroler jest naszym głównym procesem, który istnieje jako rodzic wszystkich procesów o identyfikatorze procesu 1, tj. init. Jest to proces, który rozpoczyna się wraz z uruchomieniem systemu i nigdy się nie kończy. Proces ten kończy się dopiero po wyłączeniu systemu, ponieważ nie ma procesu będącego rodzicem init.

Wcześniejsze wersje Ubuntu przed 6.10 zawierały sysvinit w starym stylu, który był używany do uruchamiania skryptów w „/etc/rcx.d ” przy każdym uruchomieniu i zamknięciu systemu. Ale potem system upstart zastąpił stary system sysvinit, ale nadal zapewnia z nim kompatybilność wsteczną.

Najnowsze wersje Ubuntu mają ten system upstart, ale od czasu ewolucji z Ubuntu 6.10 przeszło kilka wersji, aktualna wersja to 1.13.2 z dnia 4 września 2014 r. Najnowszy system upstart ma 2 procesy inicjujące, jeden dla procesów systemowych i drugi, który zarządza bieżącą sesją zalogowanego użytkownika i istnieje tylko do momentu zalogowania użytkownika, zwany także initem x-session .

Cały system został ustanowiony jako system hierarchiczny, składający się z relacji przodek-dziecko przez cały okres zasilania aż do wyłączenia systemu.

Na przykład: Mała relacja hierarchiczna pomiędzy obydwoma procesami inicjującymi to: system init(1) -> menedżer wyświetlania (przestrzeń jądra) -> menedżer wyświetlania (przestrzeń użytkownika) -> init użytkownika (lub inicjacja sesji x).

Pliki konfiguracyjne dla procesów zarządzanych przez init systemu znajdują się w „/etc/init”, a dla procesów zarządzanych przez session init znajdują się w „/usr/share/upstart” (jako według aktualnych, nowszych wersji powyżej 1.12), a te pliki konfiguracyjne są kluczem do wielu odkrytych tajemnic dotyczących procesów opisanych w tym artykule.

Coraz głębiej w hierarchię

Ubuntu rozpoznaje dwa typy procesów:

1. Praca krótkotrwała (lub praca i śmierć).
2. Praca długoterminowa (lub praca na stałe).

Hierarchia tworzona w systemie wynika z zależności pomiędzy procesami, które możemy zrozumieć przeglądając ich pliki konfiguracyjne. Zacznijmy najpierw od prostej hierarchicznej relacji pomiędzy procesami, które powodują uruchomienie systemu i zrozumienia znaczenia każdego z nich.

Hierarchia rozruchu

Init to pierwszy proces uruchamiany po włączeniu zasilania systemu i jest klasyfikowany jako zadanie work-and-stay, ponieważ nigdy nie jest zatrzymywany, a tylko w momencie zakończenia init jest włączony wyłączanie, tj. init umiera tylko raz na sesję i to jest podczas wyłączania. Po włączeniu zasilania init generuje pierwsze zdarzenie w systemie, tj. zdarzenie startowe. Każdy plik konfiguracyjny w „/etc/init” ma dwie linie definiujące zdarzenie powodujące uruchomienie i zatrzymanie procesu. Linie te są zaznaczone na poniższym rysunku:

Jest to plik konfiguracyjny procesu failsafe-x, a warunki rozpoczęcia i zatrzymania opisują zdarzenie, od którego proces się rozpocznie. Podczas generowania zdarzenia startowego przez proces inicjujący te procesy, których warunkiem uruchomienia jest uruchomienie, są wykonywane równolegle, co definiuje jedynie hierarchię, a wszystkie procesy uruchamiane podczas uruchamiania są dziećmi init.

Procesy rozpoczynające się przy uruchomieniu są wymienione poniżej i są to wszystkie zadania typu „praca i koniec”:

1. nazwa hosta – jest to proces, który po prostu przekazuje systemowi nazwę hosta zdefiniowaną w pliku /etc/hostname.

2. kmod – Ładuje moduły jądra, tj. wszystkie sterowniki z pliku /etc/modules.

3. mountall – proces ten generuje wiele zdarzeń i jest głównie odpowiedzialny za montowanie wszystkich systemów plików podczas rozruchu, w tym lokalnych i zdalnych systemów plików.

Plik /proc jest również montowany przez ten proces i po całej pracy montowania ostatnim wygenerowanym przez niego zdarzeniem jest zdarzenie systemów plików, które dodatkowo powoduje dalszy postęp hierarchii.

4. plymouth – ten proces jest wykonywany podczas uruchamiania Mountall i jest odpowiedzialny za pokazanie czarnego ekranu, który jest widoczny podczas uruchamiania systemu, przedstawiającego coś takiego jak poniżej:

5. plymouth-ready – wskazuje, że plymouth jest gotowy.

Poniżej przedstawiono procesy główne, inne, które są również uruchamiane podczas uruchamiania, obejmują np. udev-fallback-graphics itp. Wracając do hierarchii rozruchu, w skrócie następujące zdarzenia i procesy są następujące:

1. init wraz z wygenerowaniem zdarzenia startowego.

2. mountall montowanie systemów plików, plymouth (wraz z początkowym mountall) wyświetlający ekran powitalny i kmod ładujący moduły jądra.

3. Zdarzenie local-filesystem wygenerowane przez mountall powodujące uruchomienie dbus. (Dbus to ogólnosystemowa magistrala komunikatów, która tworzy gniazdo umożliwiające innym procesom komunikację między sobą poprzez wysyłanie komunikatów do tego gniazda, a odbiorca nasłuchuje komunikatów w tym gnieździe i filtruje te przeznaczone dla niego).

4. lokalny system plików wraz z uruchomionym dbus i zdarzeniem static-network-up spowodowanym przez sieć procesową, która działa również na lokalnym systemie plików. Zdarzenie powoduje uruchomienie menedżera sieci.

5. Zdarzenie wirtualny system plików wygenerowane przez mountall powoduje uruchomienie udev. (udev to menedżer urządzeń dla systemu Linux, który zarządza podłączaniem urządzeń podczas pracy i jest odpowiedzialny za tworzenie plików w katalogu /dev i zarządzanie nimi.) udev tworzy pliki dla pamięci RAM, ROM itp. w katalogu /dev te, w których mountall zakończył montowanie wirtualnych -filesystems i wygenerował zdarzenie virtual-filesystem oznaczające podłączenie katalogu /dev.

6. udev powoduje uruchomienie upstart-udev-bridge, co oznacza, że sieć lokalna działa. Następnie, gdy mountall zakończy montowanie ostatniego systemu plików i wygeneruje zdarzenie systemu plików.

7. Zdarzenie filesystem wraz ze zdarzeniem static-network-up powoduje uruchomienie zadania rc-sysinit. Tutaj pojawia się wsteczna kompatybilność pomiędzy starszym sysvinitem i nowszym…

9. rc-sysinit uruchamia polecenie telinit, które informuje poziom działania systemu.

10. Po uzyskaniu poziomu działania init wykonuje skrypty zaczynające się od „S” lub „K” (uruchamiając zadania, które mają „S” w początku ich imienia i zabijanie tych, które mają „K” na początku ich imienia) w katalogu /etc/rcX.d (gdzie „X” to bieżący poziom działania) .

Ten niewielki zestaw zdarzeń powoduje uruchomienie systemu przy każdym włączeniu. I to zdarzenie wyzwalające procesy jest jedyną rzeczą odpowiedzialną za utworzenie hierarchii.

Przyczyną zdarzenia jest teraz kolejny dodatek do powyższego. Który proces powoduje które zdarzenie jest również określone w tym samym pliku konfiguracyjnym procesu, jak pokazano poniżej w tych wierszach:

Powyżej znajduje się sekcja pliku konfiguracyjnego procesu mountall. Pokazuje zdarzenia, które emituje. Nazwa wydarzenia następuje po słowie „wydarzenie”. Zdarzenie może być zdefiniowane w pliku konfiguracyjnym jak powyżej lub może być nazwą procesu wraz z przedrostkiem „uruchamianie”, „rozpoczęcie”, „zatrzymywanie” lub „zatrzymanie”.

Zatem tutaj definiujemy dwa terminy:

1. Generator zdarzeń: taki, który ma w pliku konfiguracyjnym wiersz „emituje xxx”, gdzie xxx to nazwa zdarzenia, którego jest właścicielem lub które generuje.
2. Event Catcher: taki, którego warunek rozpoczęcia lub zatrzymania ma wartość xxx lub który rozpoczyna się lub kończy w momencie wygenerowania zdarzenia przez jeden z generatorów zdarzeń.

Zatem następuje hierarchia, a co za tym idzie zależności pomiędzy procesami:

Event generator (parent) -> Event catcher (child)

Dodawanie złożoności do hierarchii

Do tej pory musiałeś rozumieć, w jaki sposób hierarchia zależności rodzic-dziecko pomiędzy procesami jest ustanawiana przez mechanizm wyzwalania zdarzeń poprzez prosty mechanizm uruchamiania.

Ta hierarchia nigdy nie jest relacją jeden do jednego, w której tylko jeden rodzic przypada na jedno dziecko. W tej hierarchii możemy mieć jednego lub więcej rodziców dla jednego dziecka lub jeden proces będący rodzicem więcej niż jednego dziecka. Jak to się osiąga?? Odpowiedź leży w samych plikach konfiguracyjnych.

Linie te pochodzą z procesu — sieci i tutaj warunek uruchomienia wydaje się nieco zbyt skomplikowany i składa się z wielu zdarzeń, a mianowicie – lokalne systemy plików, udevtrigger, kontener, poziom działania, sieć.

Lokalne systemy plików są emitowane przez mountall, udevtrigger to nazwa zadania, zdarzenie kontenera jest emitowane przez Container-detect, zdarzenie poziomu działania jest emitowane przez rc-sysinit, a praca w sieci znów jest zadaniem.

Zatem w hierarchii sieć procesów jest dzieckiem mountall, udevtrigger i kontener-detect, ponieważ nie może kontynuować swojego działania (funkcjonowanie procesu to wszystkie linie zdefiniowane w sekcjach script lub exec w pliku konfiguracyjnym procesu) dopóki powyższe procesy nie wygenerują swoich zdarzeń.
Podobnie możemy mieć jeden proces będący rodzicem wielu, jeśli zdarzenie wygenerowane przez jeden proces jest buforowane przez wiele.

Rozróżnianie typów stanowisk pracy

Jak zdefiniowano wcześniej, możemy mieć pracę krótkotrwałą (lub pracę i śmierć) lub pracę długoterminową (lub pozostań i pracuj), ale jak rozróżnić pomiędzy ich??

Zadania, które mają warunki „uruchom” i „zatrzymaj” określone w plikach konfiguracyjnych i mają w swoich plikach słowo „zadanie” plik konfiguracyjny to zadania pracy i śmierci, które rozpoczynają się od wygenerowanego zdarzenia, wykonują sekcję skryptu lub wykonywania (podczas wykonywania blokują zdarzenia, które je spowodowały), a następnie kończą, uwalniając zablokowane przez siebie zdarzenia .

Zadania, które nie mają w pliku konfiguracyjnym warunku „zatrzymaj”, są zadaniami długotrwałymi lub zadaniami pozostań i pracuj i nigdy nie umierają. Obecnie prace związane z pobytem i pracą można dalej sklasyfikować jako:

1. Te, które nie mają warunku odrodzenia i mogą zostać zabite przez użytkownika root.
2. Te, które mają warunek odrodzenia w swoim pliku konfiguracyjnym, dlatego uruchamiają się ponownie po zabiciu, chyba że ich praca została ukończona.

Wniosek

Zatem każdy proces w LINUX jest zależny od niektórych i pewne procesy są od niego zależne, a ta relacja jest wiele do wielu i jest określona przez system początkowy wraz z innymi szczegółami procesu.