Z upstart do systemd w sobotnie popołudnie

Dzisiaj przystosowałem paczkę, którą zajmuję się w Fedorze (hdapsd) do współpracy z systemd. Systemd jest najnowszym podejściem do zarządzania w Linuksie procesami i usługami na poziomie systemu, operacji cyklicznych i sesji użytkownika.

Moją paczkę od początku wyposażyłem w skrypt współpracujący z upstart, czyli poprzednią próbą unowocześnienia tradycyjnego inita. Upstart jest stosowany w Ubuntu od 2006 roku, w Fedorze od wersji 9, czyli od 2008. Porzucenie upstart w F14 jest gruntowne — systemd współpracuje ze skryptami startowymi SysV, ale zupełnie ignoruje definicje zadań z upstart. Stąd konieczność modyfikacji.

Po kilku kwadransach czytania i modyfikowania wg. wskazówek Lennarta stwierdzam: podoba mi się systemd.

Program, który się zajmuje ma proste zadanie: zatrzymuje pracę dysku twardego, gdy któryś z akcelerometrów wykryje spadek komputera. Dla każdego z chronionych dysków hdapsd musi być uruchomiony osobno. Najlepiej jak najszybciej, żeby objąć dyski nadzorem jak tylko pojawią się w systemie. Do tego odrobina konfiguracji w pliku /etc/sysconfig/hdapsd.

Pierwszym elementem jest regułka wywoływana dla dysków twardych przez udev. Informuje systemd, że dla niewymiennych dysków sda i sdb przydałoby się uruchomić usługę hdapsd:

SUBSYSTEM=="block", KERNEL=="sd[ab]", ATTRS{removable}=="0", TAG="systemd", ENV{SYSTEMD_WANTS}="hdapsd@%k.service"

Podobną regułkę wykorzystywałem, gdy w Fedorze używany był Upstart 0.3. Wersja 0.6 nie potrzebowała regułki. Prawdopodobnie w systemd też będzie (a może już można?) obejść się bez dodatków do udev.

Druga sprawa to definicja usługi już w systemd. Plik /lib/systemd/system/hdapsd@.service wygląda następująco:

[Unit]
Description=%I shock protection daemon

[Service]
EnvironmentFile=/etc/sysconfig/hdapsd
StandardOutput=syslog
SyslogIdentifier=%p(%I)
Nice=-5
ExecStart=/usr/sbin/hdapsd -d %I $(HDAPSD_OPTIONS)

Jest tu przekierowanie standardowego wyjścia z programu do sysloga. Hdapsd ma przełącznik -l, dzięki któremu robi to sam, ale nie każdy program lub skrypt tak potrafi. Dzięki implementacji na poziomie inita programiści nie muszą pisać obsługi syslog samemu.

Uruchomienie z żądanym poziomem Nice to tylko szczyt góry lodowej możliwości regulacji. Moja dusza sysadmina szeroko się uśmiecha, gdy czytam stronę manuala systemd.exec, gdzie podane są wszystkie możliwe przełączniki. A jest ich multum: katalogi, capabilities, UID, GID, ustawienia OOM, parametry planisty I/O, klasy planisty CPU, przywiązania do procesorów itd. Pieczę nad nimi trzyma systemd, więc skrypty startowe mogą składać się z ustawień i nazwy binarki do uruchomienia. Do tej pory osiągnięcie takiej kontroli wiązało się z uruchamianiem wielu pomocniczych progamów (nice, ionice, echo > /proc/…, ulimit, setcap, chrt, su, taskset, …) a czasem wymagało skorzystania z odpowiednich wywołań systemowych już w programie.

Pochwała należy się za dokumentację, która rzadko w linuksanych programach jest odpowiednio obszerna. Systemd opisany jest wyczerpująco, a główny autor na IRCu i poprzez kanał mailowy wyjaśnia wątpliwości.

*** **Archived comments:** **Piotr Pyclik** _2010-07-17 18:00:27_

A może w przystępnych słowach, czym się różni systemd od upstart i z jakich względów ma zostać preferowanym rozwiązaniem w F14? Obserwuję rozwój Fedory, jednak programistą nie jestem, stąd to wszystko nie jest dla mnie zrozumiałe...

**zdz** _2010-07-17 18:08:30_

W przystępnych słowach, hm... Lennart opisał dokładnie u siebie: http://0pointer.de/blog/projects/systemd.html (w tym porównanie z systemd) , kocio pisał też kiedyś na linuxnews.pl , plan na F14 jest tu: https://fedoraproject.org/wiki/Features/systemd
Powtarzać tego wszystkiego raczej nie ma po co. IMO nie wymaga wiedzy programistycznej do zrozumienia.

**Paweł Ciupak** _2010-07-17 23:01:30_

> A może w przystępnych słowach, czym się różni systemd od upstart

Upstart to wymyślaniie koła od nowa, zaś systemd, to wymyślanie koła od nowa drugi raz.

**Stanisław 'dozzie' Klekot** _2010-07-18 23:17:02_

Albo też inaczej: upstart jest broken by design, bo bazuje na podaniu przez opiekuna pakietu wszystkich zależności usługi (rzecz niewykonalna, widziałem w praktyce).
systemd ma szanse działać sprawnie, bo listę zależności sporządza sam. Za usługę jest uznawane coś, co słucha na gnieździe; systemd słucha na tym gnieździe, a przy pierwszym połączeniu startuje stosowną usługę i przekazuje jej gniazdo.
Konstrukcja podobno zaczerpnięta z MacOS X.

**Marek** _2010-07-19 23:29:18_

Witam. Szukając informacji o przywracaniu ext3 do stanu spójnego po nagłej śmierci systemu natrafiłem na tę stronę. Normalnie nie zostawiłbym żadnego wpisu, ale to słońce pomagające czytać zafascynowało mnie...
Pozdro dla autora strony ;)

**zdz** _2010-08-03 07:23:02_

Piotrze: zacząłem pisać, pierwsza notka z cyklu: Krótki instruktaż systemd: wstęp