Głębokie spostrzeżenia systemu „Ubuntu Linux” - czy to widzimy?

Linux Jak wiemy, to jądro, a nie system operacyjny, wysyła kilka dystrybucji, takich jak: Debian, Fedora, Ubuntu itp. i wiele więcej. Ubuntu OS opracowany przez Mark Shuttleworth jest popularnie znany i powszechnie używany przez wielu. Również bycie wolnym i open source jego nowa wersja jest corocznie wydawana, która wkłada tysiące programistów, którzy przyczyniają się do rozwoju. Ale jak to działa? Jakie procesy, lista wydarzeń sprawiają, że działają i jakie jest znaczenie tych procesów?

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

Połóż system

Linux ma proces funkcjonowania, każda usługa systemowa, w tym zarządzanie energią, uruchamianie, obsługa awarii systemu to proces, który ma plik konfiguracyjny w „/etc/init„To opisuje zdarzenie, na którym będzie wykonywać i odpowiadające zdarzenie, na którym powstrzyma jego wykonanie, wraz z tym również utrzymuje inne pliki konfiguracyjne opisujące jego zachowanie w czasie wykonywania w systemie„ System ”/itp/”Katalog, czyniąc w ten sposób system oparty na zdarzeniu.

Jeśli generowane są zdarzenia, ktoś powinien tam być, aby je złapać i wykonać?? Cóż, oczywiście kontroler jest naszym głównym procesem, który istnieje jako rodzic wszystkich procesów z identyfikatorem procesu 1 I.mi. w tym. Jest to proces, który rozpoczyna się od uruchamiania systemu i nigdy się nie kończy. Proces ten umiera dopiero po włączeniu systemu, ponieważ nie ma procesu, który jest rodzicem INIT.

Wcześniejsze wersje Ubuntu zanim 6.10 Włączony stary styl Sysvinit To było używane do prowadzenia skryptów w „/etc/rcx.D”Katalog na temat każdego uruchamiania i wyłączenia systemu. Ale potem dorobkiewicz System zastąpił stary styl Sysvinit System, ale nadal zapewnia do niego kompatybilność wsteczną.

Najnowsze wersje Ubuntu mają ten system, ale od jego ewolucji z Ubuntu 6.10 Posunęło się kilka aktualnych wersji 1.13.2 jak 4 września 2014. Najnowszy system upstart ma 2 Init Procesy, jeden dla procesów systemowych, a drugi, który zarządza bieżącą zalogowaną sesją użytkownika i istnieje tylko do momentu zalogowania użytkownika, również nazywany X-sesja w tym.

Cały system został ustanowiony jako hierarchiczny, składający się z relacji przodka-dziecko w całej mocy, aż do władzy systemu.

Na przykład: Mała hierarchiczna relacja między obiema procesami init to: System init (1) -> Display Manager (przestrzeń jądra) -> Display Manager (miejsce użytkownika) -> initer użytkownika (lub X-session init).

Pliki konfiguracyjne dla procesów zarządzanych przez system System Init mieszka w „/etc/init”A dla osób zarządzanych przez session init mieszkają w„/usr/share/upstart”(Zgodnie z aktualnymi wersjami 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 hierarchii

Ubuntu rozpoznaje dwa rodzaje procesów:

1. Krótkie oferty pracy (lub prace robocze).
2. Długo przeżywana praca (lub praca w pracy).

Hierarchia wykonana w systemie jest spowodowana zależnością między procesami, które możemy zrozumieć, przeglądając ich pliki konfiguracyjne. Zacznijmy od prostej hierarchicznej relacji między procesami, które sprawiają, że system uruchamia się i rozumieją znaczenie każdego z nich.

Hierarchia rozruchu

W tym jest pierwszym procesem, który rozpoczął zasilanie w systemie i jest klasyfikowany w ramach praca i stojak praca, ponieważ nigdy nie jest zabijana i tylko czas, kiedy init został zabity, jest zasilanie.mi. init umiera tylko i to też raz na sesję i to jest na zasilaniu. Po zasilaniu INIT generuje pierwsze zdarzenie w systemie I.mi. Wydarzenie startupowe. Każdy plik konfiguracyjny w „/etc/init”Ma dwie linie, które określają zdarzenie, które powoduje, że proces rozpoczyna się i zatrzymuje. Te linie są podświetlone na poniższym rysunku:

To jest plik konfiguracyjny procesu FailSafe-X i zaczynają się od i zatrzymują się na warunkach opisują zdarzenie, od którego rozpocznie się proces. Na wytwarzanie zdarzenia startupu według procesów inicjujących te procesy, które mają uruchamianie, ponieważ ich rozpoczęcie w warunkach są wykonywane równolegle, a to tylko określa hierarchię, a wszystkie procesy wykonywane podczas uruchamiania są dziećmi inicjantów.

Procesy rozpoczynające się od uruchamiania są wymienione w ramach, a wszystkie są zadaniami roboczymi:

1. Nazwa hosta - Jest to proces, który po prostu informuje system nazwy hosta zdefiniowanego w pliku /etc /hostName.

2. kmod - Ładuje moduły jądra i.mi. Wszystkie sterowniki z pliku /etc /moduły.

3. Mountall - Ten proces generuje wiele zdarzeń i jest głównie odpowiedzialny za wybijanie wszystkich systemów plików na rozruchu, w tym lokalne systemy plików i zdalne systemy plików.

/Proc Plik jest również zamontowany w tym samym procesie, a po całej pracy montażowej ostatnie zdarzenie wygenerowane przez IT jest wydarzeniem systemów plików, które dalej prowadzi hierarchię dalej.

4. Plymouth - Ten proces wykonuje się na początkowym Mountall i jest odpowiedzialny za pokazanie czarnego ekranu, który jest widoczny na uruchomieniu systemowym pokazującym coś takiego jak poniżej:

5. Plymouth gotowy - Wskazuje, że Plymouth jest w górę.

Poniżej znajdują się główny proces, inne, które również wykonują uruchamianie, obejmują, takie jak Udev-Fallback-Graphics, itp. Wracając do hierarchii rozruchowej, w skrócie, następujące zdarzenia i procesy są jak w sekwencji:

1. w tym wraz z generowaniem wydarzenia startupowego.

2. Mountall Montażowe systemy plików, Plymouth (wraz z początkowym montażem) wyświetlającym ekran splasowy i moduły jądra ładujące KMOD.

3. Lokalny filesystem zdarzenie generowane przez Mountall powodujące działanie DBUS. (DBUS to szeroki system magistralny, który tworzy gniazdo, pozwalając innym procesom komunikować się ze sobą poprzez wysyłanie wiadomości do tego gniazda, a odbiornik słucha wiadomości w tym gnieździe i filtruje te przeznaczone).

4. Lokalny filesystem Wraz z początkiem DBU i zdarzeniem statycznym w górę spowodowanym przez sieć procesów, która działa również na zdarze.

5. Virtual-FileSystem zdarzenie generowane przez Mountall powoduje, że UDEV działa. (UDEV to menedżer urządzeń dla Linux, który zarządza wkładaniem urządzeń i jest odpowiedzialny za tworzenie plików w katalogu /dev i zarządzanie nimi również.) UDEV tworzy pliki do RAM, ROM itp. In /Dev Directory. Mountall zakończył montaż wirtualnych plików i wygenerował wirtualne plik.

6. Udev powoduje uruchamianie mostka w górę -dev, co oznacza, że ​​sieć lokalna jest w górę. Następnie po zakończeniu Mountall zamontowania ostatniego systemu plików i wygenerował zdarzenie systemu plików.

7. system plików zdarzenie wraz z zdarzeniem statycznym w górę powoduje działanie RC-SYSINIT. Tutaj jest kompatybilność wsteczna między starszym sysvinitem a górnym…

9. RC-SYSINIT uruchamia polecenie telinit, które informuje system systemu.

10. Po uzyskaniu runLevel init wykonuje scenariusze, które zaczynają się od 'S' Lub 'K„(Rozpoczęcie pracy, które mają”S„Na początku ich imienia i zabijanie tych, którzy mają”K„Na początku ich nazwy) w katalogu /etc /rcx.D (gdzie 'X'jest obecnym lewą).

Ten niewielki zestaw zdarzeń powoduje, że system za każdym razem go zasila. I to wydarzenie uruchamianie procesów jest jedyną odpowiedzialnością za stworzenie hierarchii.

Teraz kolejnym dodatkiem do powyższego jest przyczyną zdarzenia. 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 montażu procesu. To pokazuje wydarzenia, które emituje. Nazwa wydarzenia jest jednym z sukcesówwydarzenie'. Zdarzenie może być albo zdefiniowane w pliku konfiguracyjnym jak wyżej lub może być nazwą procesu wraz z prefiksem „start”, „uruchomienie”, „zatrzymanie” lub „zatrzymane”.

Tak więc tutaj definiujemy dwa terminy:

1. Generator zdarzeń: Taki, który ma linię „emituje xxx” w pliku konfiguracyjnym, w którym xxx to nazwa zdarzenia, które jest właścicielem lub generuje.
2. Łapacz zdarzeń: Taki, który ma swój początek lub warunek zatrzymania jako xxx lub rozpoczyna się lub zatrzymuje zdarzenie, które wygenerowało jeden z generatorów zdarzeń.

Zatem hierarchia następuje, a zatem zależność między procesami:

Generator zdarzeń (rodzic) -> Łapacz zdarzeń (dziecko) 

Dodając złożoność do hierarchii

Do tej pory musiałeś zrozumieć, w jaki sposób hierarchia rodzic-dziecko zależność między procesami jest ustalana przez Wykonanie zdarzeń Mechanizm poprzez prosty mechanizm rozruchu.

Teraz ta hierarchia nigdy nie jest relacją jeden do jednego, mając tylko jednego rodzica dla jednego dziecka. W tej hierarchii możemy mieć jednego lub więcej rodziców na jedno dziecko lub jeden proces bycia rodzicem więcej niż jednym dzieckiem. Jak to się osiągnie?? Cóż, odpowiedź leży w samych plikach konfiguracyjnych.

Te linie pochodzą z procesu - tworzenie sieci i tutaj początek w stanie wydaje - Lokalne pliki, Udevtrigger, pojemnik, RunLevel, Networking.

Lokalne fileSystems jest emitowane przez Mountall, Udevtrigger to nazwa Job, zdarzenie kontenerowe jest emitowane przez Container-Detect, RunLevel emitowane przez RC-SYSINIT, a networking to znowu praca.

Zatem w hierarchii sieć procesowa jest dzieckiem MountAll, Udevtrigger i Container-Detect, ponieważ nie może kontynuować funkcjonowania (funkcjonowanie procesu to wszystkie linie zdefiniowane w sekcjach skryptowych lub exec w pliku konfiguracyjnym procesu) Dopóki powyższe procesy generują swoje zdarzenia.
Podobnie, możemy mieć jeden proces, który jest rodzicem wielu, jeśli zdarzenie wygenerowane przez jeden proces jest buforowane przez wielu.

Wyróżniając typy zadań

Zgodnie z definicją, możemy albo krótko żyć (lub praca i umowa praca) lub długo żyć Pobyt i praca) Praca, ale jak rozróżnić między nimi??

Prace, które mają obazaczynaj na' I 'Zatrzymaj się„Warunki określone w plikach konfiguracyjnych i mają słowo”zadanie„W ich pliku konfiguracyjnym są praca i umowa Zadania, które rozpoczynają się od wygenerowanego wydarzenia, wykonują sekcję skryptu lub wykonania (podczas wykonywania blokują zdarzenia, które je spowodowały) i umierają później, wydając te zdarzenia, które zablokowali.

Te prace, które nie mająZatrzymaj się„Warunek w ich pliku konfiguracyjnym jest od dawna przeżyty lub Pobyt i praca Praca i nigdy nie umierają. Teraz prace związane z pozostaniem i pracą można dalej klasyfikować jako:

1. Te, które nie mają warunków odradzania i mogą być zabite przez użytkownika root.
2. Te, które mają warunek odradzający się w pliku konfiguracyjnym, więc ponownie uruchomi się po zabiciu, chyba że ich prace nie zostały zakończone.

Wniosek

Zatem każdy proces w Linux jest zależny od niektórych i ma pewne procesy zależne od tego, a ten związek jest wiele od wielu i jest określony w systemie Upstart wraz z innymi szczegółami procesu.