syslog-ng startowany po bindzie
Tomasz Pala
gotar at polanet.pl
Tue Nov 22 13:22:00 CET 2011
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 <gotar w pld-linux.org>
More information about the pld-devel-pl
mailing list