Na każdym zebraniu jest taka sytuacja, że ktoś musi zacząć. Przy komputerze nikt kogo pod pistoletem nie trzyma, a skoro pan nie mówi o przyrodzie, możemy przejść do spraw ciekawszych. Jeśli wiesz, czym jest dæmon init i jaka jest jego rola w systemie uniksowym, możesz śmiało przeskoczyć nad płytkim, powierzchownym i łopatologicznym wprowadzeniem, którego się nie spodziewasz, a którym za chwilę uraczę całą resztę. Wpadliście w zasadzkę, marny wasz los.
Głupi kaowiec
init nie jest wielki, ale lekceważyć go nie wolno. Jest alfą i omegą, krótkie starcie z nim szybko upewni cię, że może to oznacząć początek twojego końca. Jak to?
— pytasz ze zdziwieniem w oczach, gdy ja przypominam ci radosny komunikat:
Kernel panic: Attempted to kill init
init jest nieśmiertelny. Rodzi się jako pierwszy i, niczym dobry kapitan, pozostaje na pokładzie do samego końca. Inne procesy traktują go jako dobrotliwego wujka, który przygarnia zbłąkane sieroty, bądź jako wielkiego przedwiecznego, który wszelkie nieposłuszeństwo karze globalną zagładą.
Czy powinienem się go bać?
— zapytujesz, a twarz twą oblewa rumieniec. Nie
— odpowiadam, wzbudzając tym większą ciekawość. init to bardzo specyficzna bestia. Uruchamiany jest jako pierwszy proces przestrzeni użytkownika (nie licząc tak zwanego early userspace
zawartego w initramfs, odpowiadającego za przygotowanie urządzeń do właściwego uruchomienia systemu) i zawsze jest numerem jeden (chodzi oczywiście o PID, czyli identyfikator procesu). Przygarnia również sieroty, czyli procesy, które wyrzekają się rodziców. Jądro systemu operacyjnego automatycznie przypisuje wszystkim bezpańskim procesom zastępczego opiekuna w postaci procesu init właśnie.
Mało tego, to właśnie biografia inita zawierać mogłaby i rzekł "niech staną się inne procesy"; i poczęły się uruchamiać usługi; i zobaczył, że było to dobre.
Dæmon init pełni rolę nadzorcy całego systemu i troszczy się o to, by uruchomione zostały wszystkie niezbędne do działania komputera usługi (oczywiście mówię o działaniu w pojęciu użytkownika, komputer w pełni zadowoli się samym jądrem i użytkownika do szczęścia nie potrzebuje).
SysVinit
Dawno, dawno temu, gdy SCO nie straszyło świata patentami, a głównym zajęciem AT&T nie było sprzedawanie iPhonów stadom amerykańskich nastoletek, ci ostatni, znani jako Laboratoria Bella, opracowywali standard systemu Unix. W owych mrocznych czasach, poprzedzających erę komputera łupanego (gdy komputer zajmuje sporą część budynku, nikomu nie przychodzi do głowy naprawianie go poprzez walenie pięścią w monitor), pojawiła się koncepcja głównego nadzorcy. Sposób jego działania pozostał przez lata właściwie niezmieniony, różniąc się tylko nieco implementacją pomiędzy architekturami i pokoleniami uniksowej rodziny.
Do dziś za wzorcową implementację uznaje się ponad dwudziestoletnią skamielinę, pochodzącą ze standardu System V (właścicielom cyfowych zegarków spieszę wyjaśnić, że tak wygląda rzymska piątka). Obsługuje start usług i przypisywanie ich do różnych profili (System V posiada system siedmiu profili nazywanych poziomami i numerowanych od 0 do 6), potrafi dodatkowo wskrzeszać swoje dzieci, jeśli taka jest wola administratora.
Dlaczego zatem usługi uruchamiane są poza nadzorem systemu? Problemem jest ich elastyczna konfiguracja, możliwość zatrzymywania i uruchamiania w dowolnym momencie, a także fakt, że w przypadku problemów init z System V zupełnie nie interesuje się przyczyną nagłego zgonu.
W pozostałych rolach
Konkurencja nie spała. Pomijam systemy oparte o szkielet BSD, który jako model systemu powstał jeszcze przed System V, więc informacja o używaniu innego nadzorcy nie powinna cię zdziwić.
Najszerzej kojarzoną jest z pewnością implementacja daemontools. Jedni twierdzą, że to ze względu na kontrowersyjną postać autora, inni, że jest to wynik radykalnego podejścia do procesu nadzorcy. Rewolucyjnych zmian nie ma tam co szukać, podstawową różnicą jest większa konfigurowalność nadzorowanych usług i rezygnacja z profili uruchomieniowych. O sukcesie podejścia wystarczy powiedzieć tyle, że w 90% przypadków daemontools uruchamiane jest przez… SysVinit.
Nieco inne podejście zastosowali autorzy initng, rozwijanego przez deweloperów Gentoo. Do tradycyjnego nadzorcy dodano możliwość równoległego uruchamiania wielu usług i wprowadzono prosty system zależności. Zaowocowało to skróceniem czasu startu systemu — usługi nie musiały stać gęsiego w kolejce i uruchamiane były, gdy tylko zaspokojone zostały ich podstawowe wymagania (zaznaczyć wypada, że większość usług zadowala się działającą siecią bądź samym faktem włączenia komputera, tylko nieliczni domagają się prywatnego apartamentu z widokiem na morze).
Apple z kolei stworzyło launchd, który jest hybrydą pomiędzy tradycyjnym procesem init, dæmonem inetd i usługą cron. Podstawowym udogodnieniem dla użytkowników była tu wprowadzona możliwość uruchamiania usług na żądanie,
rozszerzona później przez grupę freedesktop.org i zintegrowana z zarządcą magistrali DBus.
upstart already!
Mamy wreszcie projekt upstart, o którym krótko opowiem. Myślałem, że nigdy do tego nie dojdziesz
— wzdychasz pod nosem, sprawdzając, czy mikrofon laptopa na pewno jest wyłączony. Pamiętaj jednak, że dla niektórych Linux to żółty pasek postępu z napisem Loading Ubuntu
i każda okazja do postraszenia ich bebechami systemu jest dobra.
upstart łączy zalety większości wspomnianych wyżej implementacji. Potrafi emulować zachowanie System V, uruchamiać usługi równolegle, wspiera zależności, a autorzy obiecują, że niedługo może też zastąpić dæmona inetd. Przejście na niego jest bezproblemowe, bo usługi ze starego do nowego formatu przenosić można stopniowo, z każdym krokiem zyskując pełen nadzór nad ich działaniem, automatyczny restart w przypadku awarii i powiadamianie administratora o występujących problemach.
upstart dodaje też unikalny system reakcji na zdarzenia, nowe procesy mogą więc zostać uruchomione lub zakończone w odpowiedzi na zmiany zachodzące w działającym systemie. Chcesz, aby system obsługi wydruku działał tylko, jeśli do komputera podłączona jest drukarka? Nie ma problemu. Zatrzymać mniej krytyczne usługi, gdy serwer korzysta z zasilania awaryjnego? Proszę bardzo. Wszystko w automatycznie i z pełnym wglądem w listę tego, co aktualnie działa, co nie działa i dlaczego.
Oczywiście, nie piszę tego wszystkiego bez przyczyny. Wczoraj upstart pojawił się w PLD i skutecznie zastąpił swego pradziadka na wszystkich moich komputerach. Daj mu szansę i zainstaluj pakiet upstart-SysVinit, a jeśli ktoś spyta cię, jaki jest cel projektu, odpowiesz spokojnie:
Attempting to kill init