Krótki instruktaż systemd: wstęp
Systemd jest kolejną
próbą wymiany procesu init
w Linuksie, dodatkowo
z ambicją zarządzania sesją użytkownika. Projektowany przez
ostatnie dwa lata czerpie garściami z upstart
(Ubuntu od 2006,
Fedora od 2008), launchd
(Darwin) i SMF
(Solaris 10).
Szeroki opis znajduje się na stronie projektu, na stronach podręcznika man
i blogu głównego autora.
Ja ograniczę się do opisania cech szczególnych. systemd
wciąż
zmienia
się pod wpływem sugestii użytkowników, więc część informacji może się
zdezaktualizować.
Wszystkie zarządzane zasoby zebrane są w jednostkach. Szczegółowy
opis będzie przedmiotem kolejnych wpisów z cyklu. Konfiguracji jednostek dokonuje
się w plikach formatu .ini
, zawierających od jednej do trzech sekcji:
-
[Unit]
zawiera informacje ogólne, jak opis jednostki, wymagania, opcje startu -
[Install]
zawiera wskazówki dotyczące włączania jednostek ( thinkchkconfig on
) - sekcja konfigurująca ustawienia właściwe dla konkretnego typu jednostki
Systemd potrafi zinterpretować wiele tradycyjnych plików konfiguracyjnych w Linuksie i tworzyć jednostki na ich podstawie. Jeśli jednak istnieje już plik konfiguracji jednostki, ma on pierwszeństwo nad tradycyjnych plikiem. Daje to możliwość stopniowej migracji systemu przez zastępowanie kolejnych plików tradycyjnych plikami natywnymi, systemd–owymi.
Siłą rzeczy systemd
jest porównywany z upstart
.
Upstart, chociaż szeroko przyjęty, rewolucji nie zrobił — większość dystrybucji
wciąż korzysta z niego w trybie zgodności z SysV. Wynika to po części ze
sposobu działania zależności w upstart
. Jest to rozwiązanie
oparte na zdarzeniach. Przykład: demony syslog, D-Bus i NetworkManager. Do działania
wymagają siebie w takiej właśnie kolejności.
W upstart
zakończony start syslog emituje zdarzenie. Na ten
sygnał startowany jest D-Bus. Zakończenie startu D-Bus jest sygnałem do uruchomienia
NetworkManagera.
Systemd zarządza usługami¹ w sposób totalny. Próba odwołania do interfejsu
NetworkManagera na szynie D-Bus jest sygnałem do startu tej usługi. NM nawiązujący
połączenie z D-Bus powoduje start tego ostatniego, a otwarcie /dev/log
wyzwala start sysloga. Możliwe jest to dzięki zarządzaniu przez systemd
gniazdami reprezentującymi usługi. Wszystkie zależności startowane są na żądanie,
jak najwięcej równocześnie. Upstart wykonuje więc zadania po kolei.
Systemd patrząc na pożądany efekt końcowy startuje usługi, które go zapewnią,
możliwie równolegle.
Zarządzanie gniazdami przez systemd
daje dodatkowy efekt uboczny
w postaci zwiększenia niezawodności komunikacji. Jeśli demon syslog zakończy się
na skutek błędu, zostanie uruchomiony ponownie przy kolejnym komunikacie do
przetworzenia. Nie zostaną zerwane połączenia z aplikacjami. Również w przypadku
zwykłego restartu syslog przez administratora połączenia nie są kończone. Nie
są tracone żadne komunikaty, dłuższy start usługi spowoduje jedynie zbuforowanie przesyłanych
danych przez jądro.
systemd
korzysta maksymalnie z typowo Linuksowych mechanizmów.
Z jednej strony powoduje to brak przenośności, z drugiej daje wygodny interfejs
do pokręteł konfiguracyjnych Linuksa.
¹ usługa to tylko jeden typ jednostki, uproszczenie przyjmuje dla rozjaśnienia opisu
Następnie: Usługi