Z upstart do systemd w sobotnie popołudnie (17 lipca 2010, 17:54:32)
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.
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...