Migracja serwisów SysV -> systemd

[Tomasz Pala]

On Thu, Jan 26, 2012 at 11:46:55 +0100, Pawel Golaszewski wrote:

>> W jaki niby sposób? Konkretnie - bo nie widzę takiej możliwości.
> 
> no jak nie widzisz? W zależności czy zainstalujesz usługę przed systemd 
> czy po systemd dostaniesz inaczej działający system.

No niestety, ale nie widzę nadal - system będzie działał dokładnie tak
samo. Miałeś może na myśli, że będzie się w innej kolejności coś
uruchamiało? To nie jest ŻADEN problem - naczelną zasadą równoległego
uruchamiania jest to, że kolejność ostateczna jest niedeterministyczna
(np. jakieś oczekiwanie na jedną usługę spowolni inne, zależne od niej,
nie spowalniając niezależnych). Bardzo dobrze to zresztą widać przy
uruchamianiu systemd z confirm_spawn=1: nie dość, że wynik jest zupełnie
inny niż normalne uruchamianie (i fakt, czasem ciężko się debuguje), to
jeszcze uruchamiane usługi 'w tle' zaśmiecają konsolę. Biegną także
timeouty usług (30 sekund), więc trzeba się streszczać, inaczej część w
ogóle nie wstanie.

> To niedeterministyczne -> nieakceptowalne.

To w takim razie musisz pozostać przy liniowym SysV (albo nawet napisać
sobie BSD!) :)
Bo sam fakt, JAK będzie uruchamiana usługa, jest jak najbardziej
deterministyczny - wszystko doinstalowane PO systemd-units będzie
uruchamiane przez systemd.

>> W momencie tego podziału reszta pakietu zastępowała całego inita. 
>> Później dopiero wydzieliłem 'compat' (tj. /bin/init oraz towarzyszące 
>> symlinki) i teraz jedyne uzasadnienie units to właśnie R/S w demonach.
> 
> Nie lepiej teraz wrzucić wszystkie unity do samego systemd?
> A tą paczkę przemianować na utils (albo jakieś commons) i wrzucać tam 
> wszystko co jest potrzebne innym aplikacjom, czyli na przykład właśnie ten 
> ctl. To byłoby najprostsze rozwiązanie...

ctl oraz unity muszą być razem - ich rozdział nie ma najmniejszego sensu.

>> No właśnie - wariant 2 i 3 możemy sobie od razu odpuścić, bo zawiodą i 
>> tak. Robota głupiego - szczególnie zważywszy na charakter PLD.
> 
> Nie o tym mówiłem.
> Nie mówimy o działaniu instalacji paczek, ale o przeniesieniu 
> _istniejącej_ konfiguracji _różniącej_ się od standardowych ustawień z 
> paczki.

To jest zdecydowanie niedopuszczalne! Nie wyobrażam sobie sytuacji, w
której system uruchamia mi usługę, która może być nieskonfigurowana i
wystawiać maszynę na ataki ze świata.

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