[Fli4l_dev] Verfügbarkeit von "metalog"

[Christoph Schulz]

Hallo!

Bernd Hampel schrieb:

>> a) auf Grund einer unerwünschten Konfiguration entsteht (etwa weil das
>> rc- Skript vom metalog-Paket etwas derartiges konfiguriert, oder weil das
>> metalog-Programm eine bestimmte Standardkonfiguration einkompiliert hat),
>> oder
> 
> Das rc-Skript ist für den Test nicht verändert worden, nur der Level
> minimum  = 6 auf 7.

Ich kenne aber weder das rc-Skript noch Metalog. Wer weiß, vielleicht 
protokolliert Metalog _immer_ auf die Konsole?

>> b) ob der Grund schlicht ein Timing-Problem ist, d.h. metalog wird zwar
>> zum Zeitpunkt rc325 gestartet, schaltet sich aber erst später "scharf",
>> so dass ihn ein Teil der Meldungen gar nicht erreicht.
> 
> Kann nicht sein, am Anfang des Logs sind alle Meldungen vorhanden und
> auch gleich mit dem vom syslogd.

Das verstehe ich nicht. Was für einen "syslogd" meinst du? Du kannst nur 
_einen_ Syslog-Dämon gleichzeitig nutzen. Oder meinst du, dass du einen 
Vergleich zwischen den Protokollen einmal vom Busybox-syslogd und einmal von 
Metalog gemacht hast?

> Wie kann ich denn testen welche Meldungen an dem Metalog-Daemon ankommen
> bevor sie verarbeitet werden?
> Damit kann man evtl. das metalog-Programm als Fehler lokalisieren.

Das ist nicht einfach. Die Kommunikation zwischen Anwendungen und Syslog-
Dämon läuft über einen Unix-Socket (/dev/log). Man könnte nun mit Hilfe von 
"socat" (Paket "tools") versuchen, einen "Mittelsmann" zu etablieren (siehe 
z.B. [1]), aber das ist nicht einfach, und ich habe es auch nicht 
ausprobiert. (Der in [1] gezeigte Weg ist nicht 1:1 anwendbar, weil /dev/log 
ein Datagramm-Socket und kein Verbindungs-Socket ist -- man müsste wohl 
UNIX-LISTEN durch UNIX-RECVFROM und UNIX-CONNECT durch UNIX-SENDTO 
ersetzen.)

[1] http://superuser.com/a/576404


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]