Na początku miesiąca przyszła większość elementów potrzebnych do kontroli umysłów rozpoczęcia Projektu 61107 i siostrzanego Projektu 1434.

Brakuje jeszcze kilku ważnych szczegółów, jak np. płytki prototypowej. Nie jest to pilny problem. Projekt(y) z założenia weekendowe, więc z uwagi na rozpoczęcie sezonu wyjazdów, jakieś efekty osiągnę pewnie za pół roku :-/

Archived comments:

DeHa 2012-04-18 16:52:00

Co będzie?

zdz 2012-04-18 16:57:14

DH: można spekulować ;-)

sprae 2012-04-18 17:02:44

Coś z podczerwienią. Tylko co to za układy ST? Na początku pomyślałem, że 555, ale to wątpliwe raczej.

mmazur 2012-04-18 19:36:22

Ja tam obstawiam, że zdzichu zacznie kręcić fetyszowate pornole z użyciem różnych części elektronicznych zamiast standardowych igieł, sznurków i takich tam.

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.