On Tue, Nov 22, 2011 at 12:44:37 +0100, Adam Osuchowski wrote: > Nie przesadzaj, jeżeli przez chwilę (pomiędzy uruchomieniem sysloga, a > uruchomieniem ntpdate/rdate) będzie rozjazd czasu to naprawdę nic na tym > nie ucierpi.
W przypadku nieistotnych i gadatliwych usług, pewnie tak. Ale w tym przypadku można równie dobrze powiedzieć, że jak parę logów zniknie, to też się nic nie stanie. > Pomijając fakt, że RTC też nie zdąży się rozsynchronizować > po jednym reboocie. O ile bateryjka działa, a wcześniej w ogóle się synchronizował. No i niekoniecznie reboot - to może być choćby i cały dzień offline (z rozładowanymi UPS-ami). Bardziej chodzi o zasadę działania - loguje się zdarzenia w czasie, a nie sam fakt ich wystąpienia, bo bez czasu są to informacje nieprzydatne. > Pytanie, czy to coś da. Skoro syslog nie słucha na głównym /dev/log, to > na tym w chroocie binda też nie. A nie wiem czy bind, gdy przy starcie > nie potrafi połączyć się do /dev/log, próbuje później jeszcze raz. Gorzej, że to zwykły socket, a nie urządzenie... Rozwiązanie brzydkie - wczesne uruchomienie sysloga, jak komuś potrzebne, a potem reload w miejscu, gdzie obecnie jest start. Rozwiązanie poprawne - jakiś mini-syslog (Arek wspominał, że systemd potrafi podtrzymać), wyłączany przez właściwego sysloga. Rozwiązanie koszerne - event-driven, konfigurujesz skrypt nameda, aby czekał na sysloga (upstart?). -- Tomasz Pala <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
