[Fli4l_dev] Verfügbarkeit von "metalog"

Bernd Hampel bernd.hampel at gmx.net
Mo Dez 14 12:20:57 CET 2015


Am 13.12.2015 um 08:21 schrieb Christoph Schulz:
> Hallo!
> 
> Bernd Hampel schrieb:
> 
>> Ich wundere mich nicht das diese meldungen auf der konsole Kommen,
>> sondern das diese meldungen im bootprotokoll (im Http) sichtbar sind.
> 
> Alle Meldungen, die auf die Konsole gelangen, kommen ins Bootprotokoll. So 
> funktioniert das Ganze. Wenn der System-Logger also so konfiguriert ist, 
> dass die Syslog-Meldungen nicht nur ins Protokoll, sondern auch auf die 
> Konsole geschrieben werden, dann siehst du genau diesen Effekt -- nämlich 
> dass die Meldungen sowohl im Syslog- als auch im Boot-Protokoll zu finden 
> sind.
> 
>> Genau diese Meldungen die im Bootprotokoll drin sind werden dann im Log
>> von metalog nicht gespeichert.
>>
>> Die Selektion im metalog.conf ist
>>   facility = "*"
>>   minimum  = 7
>>   logdir   = "/var/log/syslog"
>>
>> damit müssten aber alle meldungen  gespeichert werden.
> 
> Was ist mit Meldungen, die später generiert werden? Du kannst das mit dem 
> "logger"-Programm ausprobieren. GRundsätzlich gilt, dass es jedem Syslog-
> Dämon natürlich frei steht, wohin er seine Meldungen schreibt. Auch der 
> busybox-Syslog-Dämon kann Meldungen auf die Konsole schreiben, wenn man ihn 
> entsprechend konfiguriert:
> 
>   SYSLOGD_DEST_1='*.* /dev/console'

Die Meldungen die früher generiert werden sind alle vorhanden. weiterhin
kommen auch alle Meldungen die im Laufe des gesamten Tages generiert werden.


> Insofern müsste man klären, ob dein Problem
> 
> 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.

> 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.

> Im Falle b) kann man nicht viel machen außer zu warten (via "sleep" o.ä.).
> 
> 
> Viele Grüße,
> 
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.

Was könnte ich sonst noch ausprobieren?

Gruß Bernd



Mehr Informationen über die Mailingliste Fli4l_dev