Dokumentacja: Architektura sesji Linux

Szukam dobrej dokumentacji opisującej stos demonów i usług związanych z nowoczesną sesją Linuksa. Mimo, że przeczytałem różne dokumenty na temat dbus, i systemdnadal nie mam dużego obrazu.

W szczególności szukam odpowiedzi na te pytania (nie odpowiadaj na pytania, powinny one jedynie wyjaśnić, jakiej dokumentacji szukam):

• Który proces po zalogowaniu się jest podstawą sesji użytkownika?

• Które procesy należy rozpocząć i dlaczego? Szukam odpowiedzi niezależnej od pulpitu, bez względu na to, czy uruchomiono Gnome, KDE, FVWM, czy zwykłą powłokę.

• Jaką rolę odgrywają wszystkie te demony? Który z nich uciekłby sam, zależny od innych? Który powinien zacząć od kogo, dlaczego i na jak długo? A kto powinien utrzymywać to zoo?

Pytam, bo okazało się, że mam całe zoo demonów działających bezpośrednio po rozruchu: systemd-journald, systemd-udevd, dbus-daemon, systemd-logind. Ale nie wystarczy: Oprócz tego, Bieganie ultra-lekki PDF-Viewer zathura dodatkowo wypełnia moją sesję z dbus-launch, dbus-daemon, at-spi2-registrydi at-spi-bus-launcher, jeszcze ostatniego uruchomienia innego dbus-daemon. Żadnego z nich nie było tam wcześniej, żadnego nie zaproszono, ale zostaną w domu, dając mi przerażające uczucie, dopóki się nie wyloguję. Jestem pewien, że coś mi brakuje ...

Inny przykład: po zalogowaniu mam systemdidentyfikator UID użytkownika, ale nie mam pojęcia, co powinien zrobić (od wersji 206 myślę, że nie powinienem używać go jako menedżera sesji, prawda?). Ma proces potomny (sd-pam), o którym nie udało mi się znaleźć dokumentacji.

Co oni robią? Jaki jest pomysł tej konfiguracji?

Aby wyjaśnić moją perspektywę: w „dawnych czasach” wystarczyło wiedzieć, loginże uruchomię moją powłokę logowania ( bashwykonującą ~/.profile), i od tego momentu mogę kontynuować budowanie sesji, w zależności od okoliczności, może uruchomienia screenlub startx.

Jestem tak zafascynowany twoim pytaniem, że odpowiedziałem na nie na linuxintro . Oto odpowiedź dostosowana do twojego pytania:

Po uruchomieniu typowego komputera z systemem Linux, takim jak Fedora, SUSE lub Ubuntu, kroki będą następujące:

1. System BIOS uruchamia samokontrolę
2. BIOS ładuje sektor rozruchowy i wykonuje go
3. Program ładujący, taki jak grub lub lilo, jest wykonywany
4. Wyświetla się menu rozruchu (opcjonalnie)
5. Jądro jest załadowane
6. Początkowy dysk RAM jest załadowany
7. Jądro jest wykonywane
8. Jądro wykonuje init

9. init wykonuje, w zależności od dystrybucji, wersji i konfiguracji

   • Skrypty inicjujące SysV lub
   • systemd lub
   • dorobkiewicz

Sens wszystkich tych programów polega na uruchamianiu takich usług

• dbus, który umożliwia komunikację między aplikacjami, dzięki czemu jedna aplikacja może wywoływać funkcje z innej uruchomionej aplikacji. Jest to zwykle coś niewidocznego dla użytkowników, np. Aplikacja wywołująca menedżera okien w celu ustawienia własnego okna
• login, który pozwala użytkownikom zalogować się na terminalach CTRL_ALT_F *. Proces logowania widziany przez ps -A będzie w przypadku systemd logd systemd (może się różnić w zależności od dystrybucji)
• udev, który ma wiele nazw, np. dla mnie znajduję go z ps -A jako systemd-udevd. Przypisuje np. Uchwyty urządzenia w / dev / do podłączanych urządzeń, np. Dysku USB
• cron, który będzie wykonywał polecenia na podstawie tabeli czasowej w / etc / crontab, a także ma funkcję „@reboot” do uruchamiania poleceń podczas rozruchu.

10) proces logowania obsługiwany przez systemd będzie czekał na zalogowanie się do terminala wirtualnego, zazwyczaj można go uzyskać, naciskając CTRL_ALT_F1

11) zazwyczaj i domyślnie proces init uruchomi teraz menedżera wyświetlania, np. Kdm (menedżer wyświetlania KDE) lub xdm

12) menedżer wyświetlania uruchomi teraz system graficzny. Praktycznie nie ma systemu graficznego poza Xorg (hildon jest dla urządzeń osadzonych).

13) menedżer wyświetlania doradzi serwerowi Xorg, aby wyświetlił ekran logowania

Teraz uruchamianie jest zakończone, a komputer czeka na zalogowanie się użytkownika.

14) po zalogowaniu użytkownika menedżer wyświetlania uruchomi środowisko pulpitu, takie jak KDE, GNOME lub XFCE4. Proces rootowania dla sesji KDE użytkownika nazywa się startkde, proces rootowania dla GNOME będzie nazywany sesją gnome, proces rootowania dla XFCE4 będzie nazywał się sesja xfce4

15) KDE zwykle uruchamia wszystkie pliki wykonywalne z ~ / .kde / Autostart, a pliki .desktop z / etc / xdg / autostart (patrz zadania planowania ).

16) Gdy użytkownik zaloguje się graficznie i kliknie ikonę, aby otworzyć konsolę, zwykle wykonywana będzie bash. Bash najpierw uruchomi .bashrc

17) Gdy użytkownik otworzy powłokę logowania, oznacza to, że musi się zalogować za pomocą hasła lub autoryzowanego klucza. Może to zrobić na konsoli CTRL_ALT_F1 lub ssh'ing na komputerze, np. Localhost. Następnie zostaną wykonane skrypty .sh z /etc/profile.d i .bashrc.

Odpowiedź brzmi 42. Thorsten Staerk wyjaśnił już główny problem w komentarzach.

Aby pomóc Ci uzyskać pełny obraz, musisz wiedzieć, że oprogramowanie Linux i Open Source jest pisane i obsługiwane przez miliony wolontariuszy i firmy. Nie jest więc łatwo nadążyć za wzrostem.

Z drugiej strony jest dużo dokumentacji: strony podręcznika dla każdego oprogramowania, dobre wyjaśnienie, czym jest D-Bus , listy mailingowe dla programistów, Google i tak dalej. Poświęć więc kilka lat i przeczytaj wszystkie dokumenty dotyczące pakietów, którymi jesteś zainteresowany. Jeśli potrzebujesz go szybciej, po prostu zadaj kilka dobrych pytań w Unix i Linux .

Powodzenia.

Zanim podam moją wersję odpowiedzi, zacznę od kilku definicji

Linux == „Jądro systemu operacyjnego” Linux System == „Jakiś system zbudowany wokół jądra Linux” Sesja w systemie Linux == „Niektóre zestawy powiązanych programów użytkownika działających w systemie Linux”

Im bardziej odejdziesz od jądra, tym mniejsze prawdopodobieństwo, że dwa „systemy” będą miały coś wspólnego. Co oznacza, że ​​tak naprawdę nie ma żadnej sensownej definicji „nowoczesnej sesji Linux”

Szczerze mówiąc, oczekiwanie, że powinna istnieć jakaś nadrzędna dokumentacja systemowa, która daje ci wszystkie komponenty, jest oczekiwaniem, które po prostu nie zostanie spełnione w większości części świata open source. Programiści Open Source piszą programy do rozwiązywania (lub ponownego rozwiązywania!) Konkretnych problemów, na których im zależy - więc po prostu udokumentują tę część - jeśli tak! :-)

Możesz mieć więcej szczęścia z podręcznikami dostępnymi w komercyjnych dystrybucjach linuksa, jednak biorąc pod uwagę konserwatywny charakter większości z nich, możesz argumentować, że ich wydania nie są „nowoczesne”!

Najważniejsza rada, jaką dam, to to, że bardzo ogólny system unix / linux jest heirachiczny. Mówiłem ludziom, że lubię systemy nix, ponieważ mogłem zacząć od init, a stamtąd rozumieć wszystko, co działo się w systemie. Systemd i znajomi nieco to zmienili, ale podstawowa zasada jest taka sama - zacznij od góry i pracuj - „programy tworzące sesję” to na ogół te, które zaczęły się od momentu wejścia w dziedzic. Więc jeśli wpiszesz ssh, prawdopodobnie dostaniesz domyślną powłokę, ponieważ tak działa ssh. Jeśli zalogujesz się za pomocą interfejsu graficznego, otrzymasz wszystko, co uruchomi menedżer logowania, ponieważ tak właśnie działa menedżer logowania

Wiele frameworków pulpitu sprawia, że ​​jest to trochę trudniejsze, uruchamiając różne demony usług na poziomie użytkownika lub systemu - i czasami będą one uruchamiane na żądanie do momentu, gdy pierwszy program, który ich potrzebuje, uruchomi się - spójrz na opcje wiersza polecenia programy, które uruchamiasz, są całkiem prawdopodobne, że możesz zatrzymać to zachowanie i uruchomić aplikację w trybie „goim”.

Niestety, oznacza to, że „czytanie dokumentacji poszczególnych programów” jest jedynym sposobem na zrozumienie tego wszystkiego i że nie ma „minimalnego zestawu demonów” na sesję - jest tylko sposób, w jaki dana dystrybucja działa dla danej metoda logowania / dostępu, i to specyficzne dla dystrybucji, pulpitu i metody logowania.