Na każ­dym zebra­niu jest taka sytu­acja, że ktoś musi zacząć. Przy kom­pu­te­rze nikt kogo pod pisto­le­tem nie trzyma, a skoro pan nie mówi o przy­ro­dzie, możemy przejść do spraw cie­kaw­szych. Jeśli wiesz, czym jest dæmon init i jaka jest jego rola w sys­te­mie unik­so­wym, możesz śmiało prze­sko­czyć nad płyt­kim, powierz­chow­nym i łopa­to­lo­gicz­nym wpro­wa­dze­niem, któ­rego się nie spo­dzie­wasz, a któ­rym za chwilę ura­czę całą resztę. Wpa­dli­ście w zasadzkę, marny wasz los.

Głupi kaowiec

init nie jest wielki, ale lek­ce­wa­żyć go nie wolno. Jest alfą i omegą, krót­kie star­cie z nim szybko upewni cię, że może to ozna­cząć począ­tek two­jego końca. Jak to? — pytasz ze zdzi­wie­niem w oczach, gdy ja przy­po­mi­nam ci rado­sny komunikat:

Kernel panic: Attempted to kill init

init jest nie­śmier­telny. Rodzi się jako pierw­szy i, niczym dobry kapi­tan, pozo­staje na pokła­dzie do samego końca. Inne pro­cesy trak­tują go jako dobro­tli­wego wujka, który przy­gar­nia zbłą­kane sie­roty, bądź jako wiel­kiego przed­wiecz­nego, który wszel­kie nie­po­słu­szeń­stwo karze glo­balną zagładą.

Czy powi­nie­nem się go bać? — zapy­tu­jesz, a twarz twą oblewa rumie­niec. Nie — odpo­wia­dam, wzbu­dza­jąc tym więk­szą cie­ka­wość. init to bar­dzo spe­cy­ficzna bestia. Uru­cha­miany jest jako pierw­szy pro­ces prze­strzeni użyt­kow­nika (nie licząc tak zwa­nego early user­space zawar­tego w initramfs, odpo­wia­da­ją­cego za przy­go­to­wa­nie urzą­dzeń do wła­ści­wego uru­cho­mie­nia sys­temu) i zawsze jest nume­rem jeden (cho­dzi oczy­wi­ście o PID, czyli iden­ty­fi­ka­tor pro­cesu). Przy­gar­nia rów­nież sie­roty, czyli pro­cesy, które wyrze­kają się rodzi­ców. Jądro sys­temu ope­ra­cyj­nego auto­ma­tycz­nie przy­pi­suje wszyst­kim bez­pań­skim pro­ce­som zastęp­czego opie­kuna w postaci pro­cesu init właśnie.

Mało tego, to wła­śnie bio­gra­fia inita zawie­rać mogłaby i rzekł „niech staną się inne pro­cesy”; i poczęły się uru­cha­miać usługi; i zoba­czył, że było to dobre. Dæmon init pełni rolę nad­zorcy całego sys­temu i trosz­czy się o to, by uru­cho­mione zostały wszyst­kie nie­zbędne do dzia­ła­nia kom­pu­tera usługi (oczy­wi­ście mówię o dzia­ła­niu w poję­ciu użyt­kow­nika, kom­pu­ter w pełni zado­woli się samym jądrem i użyt­kow­nika do szczę­ścia nie potrzebuje).

SysVinit

Dawno, dawno temu, gdy SCO nie stra­szyło świata paten­tami, a głów­nym zaję­ciem AT&T nie było sprze­da­wa­nie iPho­nów sta­dom ame­ry­kań­skich nasto­le­tek, ci ostatni, znani jako Labo­ra­to­ria Bella, opra­co­wy­wali stan­dard sys­temu Unix. W owych mrocz­nych cza­sach, poprze­dza­ją­cych erę kom­pu­tera łupa­nego (gdy kom­pu­ter zaj­muje sporą część budynku, nikomu nie przy­cho­dzi do głowy napra­wia­nie go poprzez wale­nie pię­ścią w moni­tor), poja­wiła się kon­cep­cja głów­nego nad­zorcy. Spo­sób jego dzia­ła­nia pozo­stał przez lata wła­ści­wie nie­zmie­niony, róż­niąc się tylko nieco imple­men­ta­cją pomię­dzy archi­tek­tu­rami i poko­le­niami unik­so­wej rodziny.

Do dziś za wzor­cową imple­men­ta­cję uznaje się ponad dwu­dzie­sto­let­nią ska­mie­linę, pocho­dzącą ze stan­dardu Sys­tem V (wła­ści­cie­lom cyfo­wych zegar­ków spie­szę wyja­śnić, że tak wygląda rzym­ska piątka). Obsłu­guje start usług i przy­pi­sy­wa­nie ich do róż­nych pro­fili (Sys­tem V posiada sys­tem sied­miu pro­fili nazy­wa­nych pozio­mami i nume­ro­wa­nych od 0 do 6), potrafi dodat­kowo wskrze­szać swoje dzieci, jeśli taka jest wola administratora.

Dla­czego zatem usługi uru­cha­miane są poza nad­zo­rem sys­temu? Pro­ble­mem jest ich ela­styczna kon­fi­gu­ra­cja, moż­li­wość zatrzy­my­wa­nia i uru­cha­mia­nia w dowol­nym momen­cie, a także fakt, że w przy­padku pro­ble­mów init z Sys­tem V zupeł­nie nie inte­re­suje się przy­czyną nagłego zgonu.

W pozostałych rolach

Kon­ku­ren­cja nie spała. Pomi­jam sys­temy oparte o szkie­let BSD, który jako model sys­temu powstał jesz­cze przed Sys­tem V, więc infor­ma­cja o uży­wa­niu innego nad­zorcy nie powinna cię zdziwić.

Naj­sze­rzej koja­rzoną jest z pew­no­ścią imple­men­ta­cja daemontools. Jedni twier­dzą, że to ze względu na kon­tro­wer­syjną postać autora, inni, że jest to wynik rady­kal­nego podej­ścia do pro­cesu nad­zorcy. Rewo­lu­cyj­nych zmian nie ma tam co szu­kać, pod­sta­wową róż­nicą jest więk­sza kon­fi­gu­ro­wal­ność nad­zo­ro­wa­nych usług i rezy­gna­cja z pro­fili uru­cho­mie­nio­wych. O suk­ce­sie podej­ścia wystar­czy powie­dzieć tyle, że w 90% przy­pad­ków daemontools uru­cha­miane jest przez… SysVinit.

Nieco inne podej­ście zasto­so­wali auto­rzy initng, roz­wi­ja­nego przez dewe­lo­pe­rów Gen­too. Do tra­dy­cyj­nego nad­zorcy dodano moż­li­wość rów­no­le­głego uru­cha­mia­nia wielu usług i wpro­wa­dzono pro­sty sys­tem zależ­no­ści. Zaowo­co­wało to skró­ce­niem czasu startu sys­temu — usługi nie musiały stać gęsiego w kolejce i uru­cha­miane były, gdy tylko zaspo­ko­jone zostały ich pod­sta­wowe wyma­ga­nia (zazna­czyć wypada, że więk­szość usług zado­wala się dzia­ła­jącą sie­cią bądź samym fak­tem włą­cze­nia kom­pu­tera, tylko nie­liczni doma­gają się pry­wat­nego apar­ta­mentu z wido­kiem na morze).

Apple z kolei stwo­rzyło launchd, który jest hybrydą pomię­dzy tra­dy­cyj­nym pro­ce­sem init, dæmo­nem inetd i usługą cron. Pod­sta­wo­wym udo­god­nie­niem dla użyt­kow­ni­ków była tu wpro­wa­dzona moż­li­wość uru­cha­mia­nia usług na żądanie, roz­sze­rzona póź­niej przez grupę freedesktop.org i zin­te­gro­wana z zarządcą magi­strali DBus.

upstart already!

Mamy wresz­cie pro­jekt upstart, o któ­rym krótko opo­wiem. Myśla­łem, że nigdy do tego nie doj­dziesz — wzdy­chasz pod nosem, spraw­dza­jąc, czy mikro­fon lap­topa na pewno jest wyłą­czony. Pamię­taj jed­nak, że dla nie­któ­rych Linux to żółty pasek postępu z napi­sem Loading Ubuntu i każda oka­zja do postra­sze­nia ich bebe­chami sys­temu jest dobra.

upstart łączy zalety więk­szo­ści wspo­mnia­nych wyżej imple­men­ta­cji. Potrafi emu­lo­wać zacho­wa­nie Sys­tem V, uru­cha­miać usługi rów­no­le­gle, wspiera zależ­no­ści, a auto­rzy obie­cują, że nie­długo może też zastą­pić dæmona inetd. Przej­ście na niego jest bez­pro­ble­mowe, bo usługi ze sta­rego do nowego for­matu prze­no­sić można stop­niowo, z każ­dym kro­kiem zysku­jąc pełen nad­zór nad ich dzia­ła­niem, auto­ma­tyczny restart w przy­padku awa­rii i powia­da­mia­nie admi­ni­stra­tora o wystę­pu­ją­cych problemach.

upstart dodaje też uni­kalny sys­tem reak­cji na zda­rze­nia, nowe pro­cesy mogą więc zostać uru­cho­mione lub zakoń­czone w odpo­wie­dzi na zmiany zacho­dzące w dzia­ła­ją­cym sys­te­mie. Chcesz, aby sys­tem obsługi wydruku dzia­łał tylko, jeśli do kom­pu­tera pod­łą­czona jest dru­karka? Nie ma pro­blemu. Zatrzy­mać mniej kry­tyczne usługi, gdy ser­wer korzy­sta z zasi­la­nia awa­ryj­nego? Pro­szę bar­dzo. Wszystko w auto­ma­tycz­nie i z peł­nym wglą­dem w listę tego, co aktu­al­nie działa, co nie działa i dlaczego.

Oczy­wi­ście, nie piszę tego wszyst­kiego bez przy­czyny. Wczo­raj upstart poja­wił się w PLD i sku­tecz­nie zastą­pił swego pra­dziadka na wszyst­kich moich kom­pu­te­rach. Daj mu szansę i zain­sta­luj pakiet upstart-SysVinit, a jeśli ktoś spyta cię, jaki jest cel pro­jektu, odpo­wiesz spokojnie:

Attempting to kill init