Dnia 20 czerwca 2010 22:09 Jacek Konieczny <[email protected]> napisał(a): > On Sun, Jun 20, 2010 at 05:12:51PM +0200, Bartłomiej Zimoń wrote: > > Dnia 20 czerwca 2010 13:43 Pawel Kwiatkowski <[email protected]> napisał(a): > > > Dnia 2010-06-18, pią o godzinie 09:05 +0200, Bartłomiej Zimoń pisze: > > > > Witam! > > > > Mala propozycja: /var/lock jako tmpfs lub podobny > > > > Pozdrawiam > > > > > > Zgaduję, że dotyczy to pozostawiania śmieci po przemontowaniu systemu > > > plików w RO lub po nagłym padzie systemu. Ten sam problem mamy > > > z /var/run i plikami z PID-ami. Tyle że tam też są rzeczy należące do > > > pakietów. > > > > > Tez ale glownie chodzi o mozliwosc startu serwisu zanim / filesystem bedzie > > mial dostep rw > > Co znaczaco przyspiesza uruchamianie systemu zwlaszcza w systemd. > > I potem będzie debugowanie tysiąca problemów wynikłych z tego, że w imię > najszybszego uruchomienia serwisy są startowane zanim mają to czego > potrzebują (u niektórych oczywiście będzie działać u innych nie)… > > No i czy z nowoczesnym initem (a zakładam, że takim systemd jest), który > wie co w systemie uruchomił, wciąż potrzeba tego /var/lock/subsys/cośtam? >
Zgadzam sie systemd nie potrzebuje /var/lock/subsys/... ale jest ono wymagane w trybie zgodnosci z /etc/rc.d/... Zalozenie jest takie ze systemd czeka na socketach itp. do czasu wlasciwej komunikacji i wtedy dopiero uruchamia usluge. Za to tworzy te sockety juz na poczatku bo zwykle inne serwisy zwykle tylko je otworaja. W momencie gdy cos chce sie komunikowac dopiero uruchamia ten serwis i przekazuje dane. Jednak developerzy sugeruja wykorzystanie tmpfs itp. w pewnych miejscach. Mysle ze nas to nie boli? Z tym rw/ro troszke przesadzilem bo napisalem swoj serwis zakrywajacy nasz /etc/init.d/network, ktory nie byl do konca w dobrej kolejnosci uruchamiany (przed wejsciem do runlevel 3) przez co pomylka. Sam tmpfs w tamtych 2chmiejscach nie powininen wplynac niekorzystnie na aktualne rozwiazania (rc-scripts/upstart). Pozdrawiam Bartłomiej Zimoń _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
