Proces nr 1 systemu Linux - systemd

Od ponad 18 lat procesem nr 1 w systemie GNU/Linux jest init, którego obecnie zastąpić ma niejaki systemd. Zmiana tego procesu wywołuje znaczną różnice w korzystaniu z systemu Linux. Zapewne to jest powodem tego, iż wielu użytkowników system Linux znienawidziło go oraz jego autora. W tym tekście postaram się wyjaśnić jaki jest cel wymiany procesu init na systemd oraz co z tego wynika.

Otóż po załadowaniu jądra do pamięci musi zostać uruchomiony jakiś program aby coś robić. W Linuksie pierwszym procesem, który może, a nawet musi uruchomić inne procesy - głównie powłokę - jest init. Gdyby w procesie uruchamiania systemu nie została uruchomiona powłoka poprzez proces login to niemożna byłoby w żaden sposób sterować systemem - chyba, że zostanie uruchomiona usługa SSH. Jak widać pierwszy proces pełni bardzo ważną rolę w systemie i co najważniejsze działa najdłużej w systemie - w sensie czasu, a nie czasu zużycia procesora. Tak więc nie dość, że init jest pierwszym procesem, który zostaje uruchomiony i ostatnim, który jest zamykany to wszystkie pozostałe procesy w systemie są mu podrzędne w hierarchii procesów. Oczywiście nadal można oderwać się poprzez podwójnego forka, ale to już inny temat. Chodzi o to, że proces init będąc rodzicem wszystkich usług system może wykonywać prace, których nie mógłby wykonywać żaden inny proces - jest tylko jeden taki proces - jest nim proces nr 1.

Chodzi o to, że 20 lat temu wymyślono proces init, który był uruchamiany przez jądro, następnie sam odpalał skrypty z lokalizacji /etc/init.d/ i na tym jego praca się "kończyła" - mimo iż działa nadal. Przez wiele lat to wystarczało i nikt nawet nie myślał to zmieniać. Więc dlaczego dziś musimy to zmieniać?

Więc, po pierwsze to wcale nie musimy tego robić, ale obecnie system Linux używany jest do wielu różnych zadań, a jego jądro jest wyposażone w wiele mechanizmów, których wcześniej nie było. Taka kombinacja nowych możliwości i potrzeb zainicjowała poszukiwanie nowych sposobów na usprawnienie systemu. W systemie Linux bardzo często pewne jego części są przepisywane w całości na nowo, to się dzieje cały czas, tylko nie wszystkie te zmiany są widoczne gołym okiem. Z procesem init jest inaczej - dostrzeżono jego potencjał, który może rozwiązać problemy do tej pory nierozwiązane i zdecydowano się to zrobić. Mało tego, wymyślono nowe sposoby wykorzystywania pierwszego procesu i wszystkie te pomysły wcielono do systemd. Wielu uważa, że są to durne pomysły i krytykuje je, ale co ciekawe to tak naprawdę to wszystkie one wcale nie są nowe. Gdyby dokładnie to przeanalizować to okazałoby się że większość z nich doczekała się swojej implementacji w jakiś sposób. Tu różnica polega na tym, że zrobiono to kompleksowo i centralnie. Mało tego, systemd nie jest wcale pierwszy i nie mam tu na myśli Upstart lecz launchd.

Launchd to zamiennik procesu init w systemie Mac OS X, okazał się sukcesem i ktoś po prostu postanowił zrobić to samo w systemie Linux - w wyniku czego został skrytykowany - własnie tak. Jednak krytyka z czasem milknie i największe dystrybucje zaczynają wdrażać nową implementację procesy init - czyli systemd. Launchd nie miał być tylko lepszą wersją pierwszego procesu, lecz całym framework-iem służącym do zarządzania usługami. Tak też zbudowany jest systemd. Systemd to nie jeden demon lecz wiele demonów, dlatego, że koncepcja systemd obejmuje zastąpienie innych demonów takich jak inetd, acpid, udev, syslog, watchdog, cron i atd. Z pomysłu rozbudowania procesu init powstała całą warstwa, która oddzielała jądro od userlandu, i tak należy traktować systemd. Poniższy schemat obrazuje jak wiele elementów system zostało wcielone do tej warstwy.

Architektura systemd - Wikipedia

Systemd to pierwszy krok do podziału demonów na te służące do zarządzania systemem i te oferujące usługi systemowe, takie jak poczta, www itp.. Nawet proces logowania i sesji będzie realizowany w ramach frameworku systemd. Wcześniej pisałem o podwójnym forku, otóż systemd maksymalnie używa mechanizmu cgroups, który uniemożliwia dla uruchamianych procesów ucieczkę od rodzica, a tym samym brak kontroli nad takim procesem. W systemd poszczególne grupy cgroups nazywane są odcinkami (ang. slice) i możemy zobaczyć ich podział chociażby wydając poniższe polecenie.

ps xaf -eo pid,user,args,cgroup

Zabawne, bo podstawową cechą systemd miała być szybkość uruchamiania. Mimo. iż osiągnięto to poprzez mechanizm jednoczesnego uruchamiania usług, to nie ta cecha jest najbardziej widoczną dla użytkowników. Wręcz przeciwnie, jest to jedna z tych zmian, które nie są widoczne gołym okiem. Nie znaczy to, że system wcale nie uruchamia się szybciej dzięki systemd, bo to możemy dokładnie sprawdzić i przeanalizować wydając poniższe polecenie.

systemd-analyze plot> s.svg

Wynikiem jego działania będzie schemat w postaci obrazu, który przedstawia analizę procesu botowania.

Warto tu króciutko wspomnieć ja osiągnięto taki efekt, ale ważniejsze jest w tym to jakie dodatkowe możliwości daje systemd dla usług. Otóż kluczem do uruchamiania wielu usług jednocześnie jest to, że systemd tworzy sockety np. typu AF_INET dla swoich usług, następnie uruchamia te usługi. Jednak już w tym czasie inne usługi (np. B), które również zostały uruchomione ale potrzebują tej pierwszej (np. A) mogą normalnie startować, ponieważ poprzez dostępny socket usługi A myślą, że ta usługa już jest dostępna, podczas gdy tak naprawdę to systemd przetrzymuje w swojej kolejce wszystkie pakiety, które zostały wysłane do tego socketu i przekaże je do jeszcze uruchamianej usługi A, gdy ta zakończy swoje uruchamianie. Efekt będzie taki, że usługa B będzie już gotowa do działania ale brakuje jej jeszcze tylko odpowiedzi od usługi A, czyli ubocznym efektem będzie długi czas oczekiwania, co nie znaczy, że w ostatecznym rozrachunku i tak wszystkie usługi uruchomią się szybciej.
Teraz warto wspomnieć co z tego wynika. Wcześniej jeszcze tylko dodam, że koncepcja centralnego demona zarządzającego socketami to nic innego niż stary inetd. Ale powodem, dla którego komercyjne dystrybucje klasy enterprise wprowadziły systemd jest to, że dzięki takiej centralizacji wykonanej w pierwszym procesie teraz możemy zresetować serwer Apache bez utraty nawiązanych sesji np. https. Mało tego dzięki integracji demona D-Bus z systemd proces, który się zawiesi może automatycznie zostać zrestartowany.

Ciekawą sprawą jest też to, że w systemd nie tylko sockety AF_INET zostały zrównoleglone, ale zrobiono to również z socketami D-Bus (AF_UNIX), a nawet z systemem plików. O systemd można napisać jeszcze bardzo dużo, ale w tym tekście chciałem przekazać ogólną koncepcję, którą realizuje ten projekt.

Więcej informacji:
- Rethinking PID 1
- Wykipedia - systemd
- Why systemd?
- Here We Go Again, Another Linux Init: Intro to systemd
- Understanding and Using Systemd
- Intro to Systemd Runlevels and Service Management Commands