Migracja serwisów SysV -> systemd

Tomasz Pala gotar at polanet.pl
Wed Jan 25 09:26:28 CET 2012


On Wed, Jan 25, 2012 at 08:40:34 +0100, Jan Rękorajski wrote:

> To jest bardzo kiepski pomysł. Bo jak kiedyś SysVinit wyleci to
> dostaniesz system w którym nic się nie uruchamia, albo będziesz musiał
> poprawiać milion pakietów, żeby włączały usługi systemd.

A czemu SysV miałoby wylecieć? Mówisz o perspektywie 10 lat (LSB i
konieczność utrzymania 3rd party software!). Przy zastosowaniach PLD i
jego popularności śmiem twierdzić, że nikogo _zainteresowanego_ problem
nie dotknie. Nie uprawiajmy sztuki dla sztuki.

> Najlepszym rozwiązaniem jest R:systemd-units i (warunkowe) włączanie usług
> systemd w post, np coś w stylu:
> 
> if init = /sbin/init
> chkconfig --list <service> | grep -qs on && %systemd_post <service>
> else
> %systemd_post <service>
> fi

Szczególnie, jak np. nowopowstały unit dla ssh nie podniesie tejże
usługi i będzie trzeba zrobić sobie wycieczkę. Albo wyjdzie jakiś babol
przy restarcie. Albo tysiąc innych rzeczy - SysV mamy przetestowane w
maksymalnym możliwym stopniu we wszystkich wariantach, tu nie chodzi o
to, co jest 'prościej', lecz bezpieczniej. Mam wymieniać potencjalne
problemy? Demony monitorujące usługi (np. monit) odwołujące się wprost
do SysV - jak ktoś sobie napisał, to musi przerobić (a skoro napisał, to
pewnie były problemy). Albo wyłączyć w monicie i włączyć supervision w
systemd. To samo w logrotate. Dalej - ja mam przykładowo uruchomione
lokalnie 2 kopie apacha (worker dla statycznych treści i prefork za
reverse proxy do PHP).

Dodając takie %posty zmusisz mnie do aktualizowania wszystkiego z
--noscripts.

> Prościej jest wyłączyć pojedyncze, niechciane usługi niż włączać
> wszystko.

Nie - ponieważ włączenie systemd robi się JEDEN raz, a wyłączać będę
musiał przy KAŻDEJ aktualizacji.

-- 
Tomasz Pala <gotar w pld-linux.org>


More information about the pld-devel-pl mailing list