Szef kuchni poleca: Beefy Miracle t-shirts O mnie Planeta !apcoh Social
systemd: Jolu, pokaż Panom cel (08 marca 2012, 11:16:38)
Jak
pisałem dwa lata temu, systemd pozbywa się pojęcia runleveli,
dając w zamian cele. Cel jest swego rodzaju punktem
synchronizacji, w którym system zapewnia określoną funkcjonalność. Zależności
między celami, tak jak między innymi jednostkami, nie są liniowe:
Otwórzmy powyższy obrazek i zastanówmy, co ja pacze?
Na początek legenda. Czarna strzałka oznacza, że wskazywany
cel jest wymagany przez wskazujący (Requires=).
Zielona wskazuje na kolejność, wskazywany musi się aktywować
do końca, zanim systemd przejdzie do wskazywanego (After=).
Czerwona oznacza konflikt (Conflicts=). Jak widać
shutdown.target konfliktuje ze wszystkich, czyli aktywacja
shutdownu powoduje zwinięcie wszystkich innych celi.
Jak widać w górnej-lewej części obrazka: nss-lookup.target nie
wymaga network.target. Jeśli jednak z jakiegoś powodu network.target
zostanie aktywowany, to nss-lookup.target wykona się po
nim — zielona strzałka.
Przy systemd nie można za bardzo powiedzieć o kolejności przy starcie systemu. Tutaj wybiera się docelowy stan systemu i osiąga go poprzez przywołanie wszystkich zależności. Analizę co się dzieje łatwiej jednak prowadzić od końca.
Załóżmy więc, że system ma działać w trybie graficznym. Celem jest więc
graphical.target, który z grubsza można porównać z runlevelem
2. w debianowatych. 4. w Slackware, 5. w starych redhatowych, SUSE i Archu —
umożliwia logowanie użytkowników w trybie graficznym.
Jako pierwsze aktywowane zostaną wymagania sysinit.target
(A special target unit covering early boot-up scripts). Ten zaciąga
przestrzenie wymiany (swap.target), lokalne systemy plików
(local-fs.target), w tym również szyfrowane z pytaniem o hasło,
jeśli potrzeba (cryptsetup.target). Aktywacje tej trójki odbywają
się równolegle. Kiedy zakończą się aktywacje i wystartowane zostaną
usługi dla tego celu, sysinit.target zostaje osiągnięty.
Umożliwia to przejście do basic.target. Zadaniem tego jest
dodatkowo uruchomienie wszystkich gniazd, na których słucha systemd
(sockets.target). System w tym stanie może przejść do trybu ratunkowego
(rescue.target) który daje powłokę odzyskiwania systemu. Przypominając:
mamy zamountowane lokalne systemy plików, włączony swap i zainicjowane
podstawowe mechanizmy dystrybucji. Taki runlevel 1.
Tu warto wspomnieć o trybie awaryjnym emergency.target. Jest to
absolutnie minimalny stan, w którym można próbować naprawić całkowicie zepsuty
system. Odpowiada niemal uruchomieniu jądra z parametrem init=/bin/sh,
daje jednak możliwość kontynuacji normalnego uruchamiania po naprawie.
Stąd system może przejść również multi-user.target. Jest to
podstawowy stan linuksa — działają prawie wszystkie demony, użytkownicy
moga logować się na konsolach (dzięki zaciągnięciu getty.target). Pachnie
jak runlevel 3. multi-user.target nie wymaga trybu ratunkowego,
ale jeśli takowy był uruchomiony, to musi skończyć się wykonywać przed przejściem
w m-u.target — zielona strzałka.
Z aktywnego multi-user.target już tylko krok do uruchomienia
graficznego zarządcy logowania i osiągnięcia zadanego graphical.target.
Większość z tych etapów opisana jest na stronie manuala
systemd.special.
Skąd brany jest cel przy starcie systemu? Zazwyczaj wskazuje go łącze symboliczne:
/usr/lib/systemd/system/default.target -> graphical.target. Administrator
może je przesłonić podając w linii poleceń jądra frazę systemd.unit=.
Cele są punktami, do których przypisujemy usługi do uruchomienia w obecnym
stanie. Weźmy np. wiszące luzem na obrazku cele po prawej stronie. Taki
bluetooth.target aktywowany jest przez pojawienie się urządzenia
obsługującego BT:
/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_WANTS}="bluetooth.target"
i powoduje wystartowanie odpowiedniej usługi:
/etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Podobnie można np. przywiesić usługi do wystartowanie w związku z kartą dźwiękową
do sound.target.
Nie należy zapominać, że start to tylko jeden z etapów życia systemu. Wdzięczny do omówienia, gdyż powoduje kaskadę aktywacji różnych celi. W normalnym użytkowaniu jest to jednak bardzo specyficzna sytuacja i nie należy się na niej skupiać w celach innych niż akademickie.
Obrazek wygenerowany grepem z systemctl dot.
