[Gelöst] syslogd: Überlaufen der Logdatei

[kriegaex]

@Hermann: Dazwischen neue FW gebaut? Falls ja, frag Dich, was anders ist. Trivialer Kommentar, aber meistens ist es auch trivial.

 

[user098]

Die Firmware wurde vor 5 Tagen gebaut und einmal eingespielt. Seit dem keine blieb es bei dieser Firmware. (War die Frage so gemeint??)

 

[kriegaex]

Die Frage war nicht an Dich, sondern an Hermann gerichtet, der nach Dir gepostet hat. Entschuldige die Verwirrung.

 

[hermann72pb]

@kriegaex: Ja, habe ich, die 33-Firmware für 7050. Hatte auch geschrieben. Aber alleine damit kann es nicht zusammenhängen, denn user098 hat doch auch 33-Firmware. Bei ihm zeigt aber free übliche Werte. Naja, sei es drum. Bevor wir hier weiter philosophieren, beobachte ich es erstmal weiter.

Zum Ringpuffer. Erstaunlicherweise läuft bei mir das Loggen in Ringpuffer seit einigen Tagen auch ohne Aufhängen und Abstürzen. Deswegen wiederhole ich meine Vermutung: kann sein, dass diese syslogd-Probleme (mit Ringpuffer und überhaupt) nur bei den Boxen mit frisch installiertem syslogd auftreten?

MfG

 

[kriegaex]

Vielleicht stimmt da was nicht recht mit der Puffer-Behandlung, vgl. dort. Ich komme zu (fast) nichts, werde es mir aber mal anschauen (obwohl nie C programmiert, erkenne ich evtl. etwas), vielleicht auch Oliver. Kannst ja auch mal in den Sourcecode 'reinspitzen.

 

[hermann72pb]

Naja, das Problem ist, wir wissen nicht genau, wonach wir suchen müssen. Und so ist es nicht besser, als schwarze Katze in einem dunklen Raum zu suchen. Bei mir läuft syslogd nun auch mit Ringpuffer gut. Warum auch immer.
Ein Posting weiter in deiner Zitat erzählt einer, wie er wunderbar mit seinem Perl-Skript die tatsächliche Puffergröße angezeigt bekommen hat, die mit der in logread ermittelten nicht überein stimmte. Wir haben kein Perl auf der Box, aber vielleicht hat jemand eine Idee, wie man die Puffergröße alternativ kontrollieren kann? Das würde ich als erstes machen: Das Problem eindeutig erkennen und reproduzieren können. Erst dann kann man mit Gegenmaßnahmen anfangen.

MfG

 

[kriegaex]

Deshalb ja der Blick in den Quellcode. Und was Perl betrifft - es gibt auch in ds26 eine Skriptsprache mit guter Systemnähe - Lua. Dann gibt es noch gdb... Möglichkeiten sind da, wenn man sich mit den Werkzeugen auskennt.

 

[kriegaex]

Kleiner Patch für syslogd und logread zum Testen

(Ausnahmsweise neuer Beitrag, weil klarer Themenwechsel.)

Hallo zusammen!

Bezugnehmend auf das hier, habe ich mal einen Patch (anbei) bei uns eingecheckt. Ob er das Problem behebt, weiß ich nicht.

Patch syslogd and logread in order to get rid of a bug described here:
http://busybox.net/lists/busybox/2007-August/028507.html
If this also helps fix the DS-Mod problems with syslogd described under
http://www.ip-phone-forum.de/showthread.php?t=136895
is unsure and yet to be tested. What went into this patch is basically this:
http://busybox.net/cgi-bin/viewcvs.cgi?rev=19470&view=rev
I.e. the BB 1.5.1 versions of syslogd and logread have been partly patched to
the post-1.6.1 BB trunk.

NOTE: Yet to be tested, just copied to the box on the fly and briefly called
both binaries.​

Und da kommt Ihr ins Spiel - bitte testen und berichten.

# 1. Patch-Archiv im Mod-Basisverzeichnis speichern

# 2. Patch entpacken
tar xvjf bb151_syslogd_ringbuffer_patch.tar.bz2

# 3. BusyBox neu bauen
make busybox-dirclean
make busybox-precompiled

# 4. Auf der Box testen...
make

 

[hermann72pb]

Das Problem ist, Alexander, die Box wieder in den Zustand zu versetzen, wo sie ab und zu rebootet. Ob es mir gelingt, weiß ich nicht. Ich versuche einfach wieder Ringpuffer auf meiner 7050 mit 15.1 und OpenVPN zu aktivieren. Vielleicht noch Kernelausgaben einschalten, damit es schneller voll läuft. Wenn die Box dann wieder ab und zu "einfriert", dann gehe ich mal mit Experimenten weiter vor.

Aber eine Frage zum patch selbst und zum Problem in der Mailingsliste. Ich hatte es gestern oberflächlich gelesen. Ist es denn überhaupt unser Problem, was sie dort diskutieren? Denn bei denen bleibt der Pointer einfach stehen, sprich aus meiner Sicht es wird einfach nicht weiter gelogt. Ob es denn solche totale Konsequenzen hat wie bei uns, weiß ich nicht. Ich teste aber trotzdem.

MfG

 

[kriegaex]

Siehe mein Kommentar: Ich weiß es auch nicht, sonst würde ich Euch ja nicht bitten, es zu testen. Für mich hört es sich auch nach etwas anderem an, aber ich habe hier schon die tollsten Nebenffekte erlebt.

P.S.: Wieso 15.1? Wir sind doch bei 15.2.

 

[hermann72pb]

Wieso 15.1? Wir sind doch bei 15.2.

Weil ich letzte Zeit etwas trage bin, vor allem mit der 7050. Da muss man nach jedem make noch einiges per Hand einpflegen. Und ich fahre auch immer zweigleisig mit 7170. Demnächst vielleicht noch 7141 oder 7113.
Aber zurück zum Thema: Ich habe bei meinem Vesruchskaninchen 7050 nun heute am 14.08.2007 um etwa 8:30 das Loggen auf Ringpuffer umgestellt. 16kB sind auch aus der Eingabemaske rausgeflogen. Es wird also voll mit default-parameter gestartet, so wie es damals zu Problemen führte.

Edit 10:35: Nun habe ich auch plötzlich

Internal socket error (-3).

auf webif. Erinnert es dich an etwas, Alexander?

mit

Aug 14 10:39:12 fritz user.err webcm0: Second instance already running

im Ringpuffer. Warum er den zweiten webcm starten will, weiß ich nicht.
top aus PUTTY:

Mem: 27932K used, 2420K free, 0K shrd, 2012K buff, 11176K cached
Load average: 3.19 3.07 2.83
  PID USER     STATUS   VSZ  PPID %CPU %MEM COMMAND
  568 root     R       3092   567 [COLOR="Red"][B]49.0[/B][/COLOR] 10.1 webcm
 2552 root     R       1452     1 [COLOR="Red"][B]49.0[/B][/COLOR]  4.7 sh
  816 root     R       1436   771  1.5  4.7 top
  770 root     S       1188  1091  0.1  3.9 dropbear
  423 root     S N     8236     1  0.0 27.0 ctlmgr
  597 root     S <     7224     1  0.0 23.7 voipd
  585 root     R       4500     1  0.0 14.7 dsld
  573 root     S       3932     1  0.0 12.9 multid
  593 root     S       3328     1  0.0 10.9 telefon
 1163 root     S       2932     1  0.0  9.6 openvpn
  617 root     S       2092   423  0.0  6.8 capiotcp_server
  924 root     S       1544   892  0.0  5.0 callmonitor
  892 root     S       1544     1  0.0  5.0 callmonitor
  922 root     S       1544   892  0.0  5.0 callmonitor
  920 root     S       1544   892  0.0  5.0 callmonitor
  771 root     S       1452   770  0.0  4.7 sh
......

MfG

 

[kriegaex]

Wenn Du mir sagen kannst, wie ich das auf meiner 7170 reproduziere, kann ich mal schauen, aber ansonsten müßtest Du selbst weiter forschen.

 

[hermann72pb]

11:00 Die Box ist erstmal weg.... Das ging aber schnell. Jetzt müßt ihr bis abends warten, bis ich zuhause bin und den Stecker mal gezogen habe.
Ich weiß nicht, Alexander, ob es bei einer 7170 überhaupt auftritt. Syslogd auf default Einstellungen stellen. Mit Ringpuffer und einem leeren Feld für die Puffergröße. Außerdem sollte OpenVPN oder etwas ähnlich monströses da am Laufen sein. Bei mir sitzen noch binaries im RAM.

Ich könnte natürlich eingreifen und webcm neu starten. Hatte ich mal irgendwann gemacht. Diesmal wollte ich es aber dem Schicksal überlassen.

13:00 Die Box ist doch wieder da. Ob es Internetprobleme waren, bezweifele ich. Webif ist immer noch nicht erreichbar. OpenVPN hat anscheinend Tunnel neu aufgebaut. Auszüge aus dem Ringpuffer:

Aug 14 13:14:18 fritz user.err webcm[830]: Couldn't load shared library  libavmssl.so - File not found - Success (0)
....
Aug 14 13:14:42 fritz user.warn kernel: /proc/tffs: info request: success
....

13:20 Nun habe ich webcm und httpd auf port 80 gekillt und

httpd -p 80 -h /usr/www/all

neu gestartet. Webif geht jetzt. Die box hat nicht neu gebootet oder reconnected.

top zeigt immer noch ein sh:

Mem: 27648K used, 2704K free, 0K shrd, 2012K buff, 11176K cached
Load average: 2.30 2.63 2.89
  PID USER     STATUS   VSZ  PPID %CPU %MEM COMMAND
 2552 root     R       1452     1 98.2  4.7 sh
 1047 root     R       1436   979  1.3  4.7 top

den kille ich auch.
Komisch, 2552 lass sich nicht killen. Egal. Weiter beobachten.

17.08 11:00 Bis jetzt lief die Box einigermassen fehlerfrei. Auch keine außergewöhnliche Meldungen im syslog. Nun habe ich heute über OpenVPN etwas auf dem AVM-WebIF rumgespielt. Und zwar mit der Anruflieste. Einfach den Button "Alle 399 Anrufe anzeigen" gedruckt. Danach hat sich die Box rebootet. In 2-3 Minuten war sie wieder da.

Fazit: Es ist schon nicht einfach so ein syslogd-Fehler zu reproduzieren. Bei mir hat es diesmal paar Tage gedauert, bis sich die Box neu startete. Damit es passiert, muss anscheinend RAM richtig voll sein. Dies kann man dadurch erreichen, dass man Pakete auslagert (wie ich es mache) und dazu noch die Box RAM-mäßig "ins Schwitzen treibt". Letzteres kann man provozieren, wenn man z.B. über OpenVPN auf der Box rumsurft, einen ALDI-PC mit Linux per WLAN + WPA mit der Box connectet (da lief bei mir auch etwas schief, weil sich die Intel-Karte ständig reconnected hatte), mehrere Telefonate mit einem eingeschalteten Callmonitor gleichzeitig macht. Oder am besten alles gleichzeitig.


Ich werde demnächst die 15.2 mit dem syslogd-patch kompillieren und dann weiter testen.

MfG