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 |
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.
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
