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