On Mon, Nov 28, 2011 at 19:48:45 +0100, Jacek Konieczny wrote: >> W ten sposob mozemy krokowo przejsc na systemd. > > Ale czy trzeba przechodzić i czy na pewno akurat na to?
Nie trzeba, ale SysV się wyczerpało wraz z rosnącymi możliwościami sprzętu oraz liczbą usług, jakie dzisiaj startują. Każda z nich powoduje wykładniczy rozrost skryptów startowych, zależności i miliona rzeczy, które mogą się popsuć, a nie mamy mocy przerobowych, żeby te skrypty pisać (ani nawet rozsądnie ułożyć koleność startu). Zresztą pisanie tych skryptów to marnowanie mocy przerobowych w każdej dystrybucji... Czy akurat to? Skoro upstart to w zasadzie Canonical, nie bardzo mamy wyjście. > Ja do końca do tego systemd nie jestem przekonany. Szczególnie > niespecjalnie podoba mi się idea 'startowania serwisu wtedy, gdy coś > próbuje z niego skorzystać' (BTW. w Upstart już też się chyba tak da) Ale to jest tylko opcja. Docelowo ma zastąpić rc-inetd, które przecież robi dokładnie to samo (w 20 implementacjach, tak jak crony). > ??? jak mam zbootowany serwer, to chcę mieć pewność, że wszystkie usługi > już działają, a nie, że może zadziałają, gdy ktoś się do nich odwoła. No właśnie szczególnie na serwerach chcę mieć coś normalnego, żeby: 1. mieć pewność, ŻE działają (bez pisania kolejnego *.monit), 2. mieć możliwie szybki start (bo 10 minut czekania to stanowczo za dużo). Jak np. dzisiaj sprawdzasz, czy jakieś usługi się nie wywaliły? Bo jeden systemctl pokazuje wszystko. A np. squid miał (dalej ma?) 30 sekundowego sleepa w stop... > Może dałoby się jakoś sprytnie i Upstart i systemd wspierać? Jestem w > stanie się pogodzić z porzuceniem 'normalnych' skryptów w init.d/ (ale > jakieś wrappery na Upstart/systemd powinny zostać, dla kompatybilności z > LSB). Dałoby się oba, tylko podejrzewam, że upstarta będzie trzeba wspierać, a 'skrypty' startowe do systemd zaczną pojawiać się w źródłach (większość demonów to trywialne 'odczytaj opcje i sforkuj się' - porównaj te nasze init.d). Bo systemd to także jednolity mechanizm upadlania się (znaczy demonowania). -- Tomasz Pala <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
