Przez wiele lat rozwoju Linuksa deweloperzy dystrybucji dokładali kolejne klocki do układanki. Ilość uruchamianych usług rosła w dużym tempie a rozwój sprzętu (głównie chodzi o szybkość dysków twardych, ale można by było wymienić inne czynniki) nie był w stanie zrekompensować negatywnego skutku tego zjawiska jakim było wydłużanie się czasu uruchamiania systemu. Punktem kulminacyjnym tego szaleństwa było chyba siódme wydanie Fedory, którym w po standardowej instalacji z live cd na okienko logowania trzeba było czekać prawie półtorej minuty (więcej po zainstalowaniu kolejnych usług). Taki stan rzeczy był w głównej mierze winą przestarzałego sposobu/filozofii uruchamiania systemu.
Wielu ludzi szukało rozwiązań, dzięki którym system mógłby być uruchamiany szybciej. W tym czasie było dostępnych kilka ciekawych rzeczy – minit, initng, runit itd. Jednak te narzędzia nie były gotowe do użycia w większych dystrybucjach – brak wsparcia dla SELinuksa, nie były używane przez szersze grupy ludzi, więc miały dużo problemów wieku dziecięcego. Pojawił się również upstart z którym wielu ludzi wiązało bardzo duże nadzieje. Dystrybucje szybko zaczęły wspierać to rozwiązanie. Jednak z powodu nie działającego systemu zależności między skryptami nie dało się używać równoległego startu usług, więc na dobrą sprawę Upstart nic nie wniósł poza marketingowym „pracujemy nad nowoczesnym sposobem uruchamiania systemu”.
Po wprowadzeniu upstart deweloperzy zaczęli się zastanawiać jak jeszcze skrócić czas startu systemu. Jeremy Katz zauważył, że niesłychanie dużo czasu system poświęca na uruchomienie przyległości jądra. Był to czas w którym większość dystrybucji miała własne skrypty służące do tworzenia initrd i wczytywania potrzebnych modułów przy starcie. Ponieważ w każdej dystrybucji był inny zestaw narzędzi, wiele miało różne możliwości – niektóre obsługiwały iSCSI/multipath/LVM/etc inne nie itd. Jeremy zauważył potrzebę napisania na nowo narzędzia służącego do tworzenia initramfs w Fedorze ale równocześnie zaprosił do współpracy również deweloperów innych dystrybucji. Dzięki temu został stworzony Dracut – bardzo uniwersalne narzędzie służące do tworzenia initrd posiadające wsparcie dla najpopularniejszych systemów.
Dracut posiada bardzo duże możliwości uruchamiania systemu – obsługuje wiele możliwych scenariuszy uruchamiania systemu – od najprostszych konfiguracji, przez takie z szyfrowanymi dyskami, po iSCSI/FCoE. Poza tym, bardzo ważną zmianą było patrzenie się na sposób uruchamiania skryptów initrd przez pryzmat szybkości startu systemu. Dzięki takiemu podejściu aktualnie rozwojowa wersja systemu (z włączonym debugowaniem) skrypty initrd wykonuje naprawdę szybko – już po 9 sekundach oddaje sterowanie do init (na Phoronix można zobaczyć testy z paru wersji Fedory) – wcześniej był to o wiele dłuższy czas – nawet do 20 sekund przy dużo mniejszych możliwościach starego mkinitrd. Dracut został szybko zaadaptowany przez inne dystrybucje. Niedawno Amadeusz Żołnowski ukończył swój projekt SoC którego celem było dostosowanie Dracut do potrzeb Gentoo (i vice versa). Teraz Dracut działa w kilku najpopularniejszych dystrybucjach. Jedną rzecz udało się w końcu zunifikować. 🙂
Jednak sukces Dracuta nie wprowadził radykalnej zmiany do nadal mocno kulawego sposobu startu dystrybucji Linuksa. Upstart nie spełnił pokładanych w nim nadziei – przez długi czas SJR nie był w stanie dostarczyć wersji z działającymi zależnościami dla równoległego uruchamiania skryptów. Gdy już pojawiła się taka wersja, to zapowiedział, że dla wersji 1.0 i tak składnia natywnych skryptów zostanie zmieniona, więc z przesiadką najlepiej poczekać do tej wersji. Więc stan w większości dystrybucji był taki, że „nowoczesny” Upstart nadal uruchamiał przestarzałe skrypty. Ten stan rzeczy nie podobał się Lennartow Poetteringowi z Red Hat i Kayowi Sieversowi z Novella. Rozpoczęli oni pracę nad systemd – nowoczesnym systemem startowym, który ma zastąpić nie spełniający oczekiwań Upstart. Jako główne cele projektowe zostały wybrane dwa:
- uruchamiać mniej
- uruchamiać więcej rzeczy równolegle
Lennart zauważył, że aktualne skrypty startowe używają strasznie dużo programów przez co po uruchomieniu systemu PID pierwszego programu jaki uruchamia użytkownik jest dość wysoki. Postawił sobie za cel zmniejszenie tej liczby – ma to być wskaźnik tego, że system startowy nie korzysta z wielu zewnętrznych programów. Lennart doszedł do wniosku, że wiele rzeczy do których w tradycyjnych skryptach startowych są używane zewnętrzne programy, może zostać po prostu napisanych w C przez co zmniejszy się narzut czasu potrzebnego na ich wykonanie. Taka filozofia spotkała się z dość ostrą reakcją niektórych konserwatystów „jak to, to już nie będzie można łatwo edytować skryptów startowych?”. Jednak trudno było nie odmówić rozumowaniu Lennarta racji – w końcu na przykład takie montowanie systemu plików /proc czy ustawianie hostname w większości dystrybucji wygląda tak samo. Dlaczego ma to być robione przez skrypty startowe a nie przez daemona uruchamiającego system?
SystemD miał być flagową funkcjonalnością Fedory 14. Jednak decydenci doszli do wniosku, że pomimo wielkich starań Lennarta nie mogą ryzykować wprowadzenia tak wielkiej zmiany z powodu bliżej nie sprecyzowanych problemów, które mogłyby wystąpić w jej następstwie. Po tej bardzo kontrowersyjnej decyzji Lennart nie zraził się i zaczął pracę nad wprowadzeniem kolejnych dużych zmian w swoim daemonie.
Dzisiaj została wydana wersja v12 SystemD. Od pierwszego commitu, który miał miejsce prawie rok temu (bez jednego dnia) zostało wprowadzonych 1750 zmian, z których każda coraz bardziej przybliża użytkowników dystrybucji Linuksa do przesiadki na naprawdę nowoczesny system init. Wszystkich zmian naprawdę nie sposób opisać – nawet trudno wybrać najważniejsze. Dlatego odsyłam do listy zmian w repo. Również warto zajrzeć do TODO, bo ujawnia ono ciekawe zamierzenia na przyszłość.
Dzisiaj pojawiły się nowe skrypty startowe dla Fedory (tu jest initscripts a tu systemd v12). Jest to „oficjalne” przejście Fedory na SystemD. Główne skrypty zostały wyczyszczone z archaicznych i zbędnych w erze SystemD rzeczy oraz zostały podzielone, dzięki czemu ich uruchamianie może być równoległe. Nowa wersja skryptów dla SystemD ma niecałe 15 kb. Stare skrypty to jakieś 60 kb kodu, który nie był nigdy uruchamiany równolegle.
Jak to wszystko się sprawuje można zobaczyć na załączonym bootchart.
SystemD wspiera cztery popularne dystrybucje – Arch, Fedorę, Gentoo, SUSE – niestety deweloperzy Debiana nie zdecydowali się na przejście na SystemD z prozaicznego powodu – brak wsparcia dla innych systemów niż Linux.
Powoli w Linuksie są wprowadzane zmiany, dzięki którym ten system sporo zyskuje. Mam nadzieję, że dystrybucje Linuksa zaczną iść drogą wprowadzania kolejnych optymalizacji i usprawnień, a nie drogą wrzucania kolejnych wodotrysków.
