[gelöst] Stabilitätsprobleme mit XX.04.37

DPR

Neuer User
Mitglied seit
2 Jul 2005
Beiträge
173
Punkte für Reaktionen
0
Punkte
0
Seit ich die Version ds26-15.1 mit der neuen Firmware 29.04.37 auf meiner 7170 habe, bootet meine Box immer wieder spontan neu. Im Schnitt etwa ein bis zwei Mal pro Tag.

Ich habe keine Ahnung an was es liegt, weil es nicht wirklich von Hand reproduzierbar ist. Ich merke es halt nur, wenn die Internet-Verbindung auf einmal abbricht und ich per "uptime" sehe, dass sich die Box gerade neu gebootet hat.

Meine Pakete:
- syslogd
- callmonitor (inaktiv)
- dropbear
- stunnel
- virtualip
- wol

Hat sonst keiner Probleme ? Ist das dasselbe Symptom das schon mehrfach mit den älteren Boxen und den neuen Firmwares+dsmod beobachtet wurde ? Ist der syslogd schuld ? Geht der Box der Speicher aus ?

Ich bin ziemlich ratlos, weil logischerweise keine Logs nach dem Reboot zur Verfügung stehen. Irgendeine Idee ?!?!?!

Update (23.7.):
Fehler wurde von AVM bestätigt, es liegt an den UPnP Einstellungen und dem igdd, NICHT am dsmod. Vorübergehend sollte man also die UPnP Einstellungen deaktivieren, weil ansonsten der Box in regelmäßigen Abständen der Speicher ausgeht und ein Reboot deswegen durchgeführt wird.

AVM-Support schrieb:
[...]
Das Problem wird in der kommenden Firmware behoben sein.
[...]
empfehlen wir die vorübergehende Deaktivierung von UPnP in der FRITZ!Box.

Update (23.9.):
Seit Version 29.04.39 ist das Problem behoben !
 
Zuletzt bearbeitet:
Kannst du mit dem Syslog irgendwohin loggen? z.B. an einen PC der an ist, oder auf einen NFS-Share

MfG Oliver
 
Den letzten Reboot gab's 10 Minuten nachdem ich den Beitrag geschrieben habe :(

Ich werde versuchen den syslogd mal so einzurichten, dass er übers Netzwerk auf einen anderen Rechner logged. Kann aber eine Weile dauern bis ich dazu komme und Ergebnisse habe ...

Edit: Habe gerade einen MP3-Player angeschlossen um darauf zu loggen - und bumm, die Box bootet neu. Irgendwas ist definitiv faul !
 
Zuletzt bearbeitet:
Logge lieber übers Netzwerk, mit USB-Speichern gibt es momentan verbreitet Probleme. Unter Windows kann z.B. Kiwi Syslog Daemon als "Empfänger" hilfreich sein.

Ansonsten läuft meine Box mit ziemlich ähnlicher Konfiguration stabil. Syslogd läuft bei mir, Callmonitor auch (mit einer einzigen Regel für Wake-on-Call, sonst nichts), Dropbear ständig, Matrixtunnel ab und zu (statt STunnel), WoL auch, aber kein VirtualIP (Portfreigaben von außen auf die Box mache ich direkt über die ar7.cfg).
 
Ok, jetzt war's vor gerade 6 Minuten wieder so weit, dass die Box einen Neustart hingelegt hat.

Die letzte Meldung ist ca. 2 Minuten vor dem Reboot (IPs unkenntlich gemacht)
Code:
Jul 16 16:31:02 fritz user.info kernel: kdsld: DSL(internet): rcv_packet_filtered xx.xxx.xxx.xxx -> xx.xxx.xxx.xx

Die einzigen Einträge davor sind einige andere "rcv_packet_drop" und "rcv_packet_filtered".

:(

Ich bezweifle, dass die was mit dem Reboot zu tun haben.
 
Wenn dir Alex's-Lösung zu schwierig zu realisieren scheint, kannst du mein Workarround ausprobieren. Lese dir bitte unsere Diskussion durch und finde im Posting #3 meine Lösung. Wenn diese Lösung dich zum Erfolg bringt, bitte sofort melden. Alex glaubt mir immer noch nicht wirklich, dass mit Ringpuffer etwas faul ist ;)
Dieses mysteriöse Ringpuffer-Problem scheint nur bei frisch aufgesetzten ds-mods mit syslogd sporadisch aber nicht immer aufzutreten.

MfG
 
hermann72pb schrieb:
Dieses mysteriöse Ringpuffer-Problem scheint nur bei frisch aufgesetzten ds-mods mit syslogd sporadisch aber nicht immer aufzutreten.
Ich verwende ja schon gar nicht mehr den Ringpuffer zum loggen, sonst hätte ich ja nach dem Reboot keine Log-Ausgaben mehr.

Momentan logge ich nach "/var/media/ftp/USB-Partition-0-1/messages", also in eine Datei auf einem USB-Speichermedium. Das funktioniert nach einem einmaligen Absturz (siehe Oben) beim Anschließen des Mediums auch einwandfrei. Alex's Vorschlag das doch übers Netz zu machen, werd ich mir vielleicht mal die nächsten Tage ansehen, weil ich dafür den syslogd meines Linux umkonfigurieren muss.

Irgendwie muss es eine Möglichkeit geben hier systematischer vorzugehen bei der Fehlersuche. Eventuell die Verbosity des Kernels hochstellen ?!
Ich hab wenig Lust nacheinander jeden Dienst zu deaktivieren und jeweils einen Tag lang zu beobachten ob die Box sich neu startet oder nicht.

Vielleicht schreib ich mir auch mal ein kleines Script, das "/proc/meminfo" und detaillierte Infos über alle laufenden Prozesse in regelmässigen Intervallen in eine Datei abspeichert.
 
Zuletzt bearbeitet:
Okay, systematischer: Poste bitte die komplette .config, welche zum Bauen der gerade bei Dir installierten FW verwendet wurde. Falls Du nicht sicher bist, ob Du sie geändert hast, bitte nochmal neu bauen. Dann hätte ich gern ggf. Kopien von debug.cfg und rc.custom (Privates anonymisieren) und im Idealfall auch ein Komplett-Backup (via Mod-Oberfläche) Deiner Einstellungen. Hier wird das Anonymisieren etwas aufwendiger, aber ich kann Dir auch per PN eine E-Mail-Adresse mitteilen, wohin das Ganze soll.

Edit: Evtl. verwendete Add-Ons und Patches bitte auch nicht vergessen.
 
kriegaex schrieb:
Okay, systematischer: Poste bitte die komplette .config, welche zum Bauen der gerade bei Dir installierten FW verwendet wurde.[...]
Die ".config" werde ich dir heute irgendwann im Verlaufe des Abends zuschicken, sobald ich wieder Zugriff darauf habe. "debug.cfg" und "rc.custom" gibt's bei mir nicht, habe keine Anpassungen vorgenommen.

Ich habe durch kurzzeitige Beobachtung des Speicher-Verlaufs inzwischen im Verdacht, dass der Box der Speicher ausgeht. Wobei ich das wie gesagt noch genauer untersuchen werde indem ich jeden Prozess detailliert über die Zeit beobachten lasse.
 
VmSize und VmRSS aller Prozesse aus /proc/status holen

In /proc/<PID>/maps siehst Du mehr zum einzelnen Prozeß, also was er so alles geladen hat. Dann kannst Du noch /proc/<PID>/status beobachten, solche Sachen wie VmSize, VmRSS, VmData. Schau mal bei allen "verdächtigen" Prozessen, welche hier mit der Zeit auffälliges Wachstum zeigen, um evtl. Speicherfresser zu finden.

Update: Ich habe Dir etwas gebastelt, mit dem Du alle Prozesse abfragen kannst. Den Einzeiler auf Deine Bedürfnisse anzupassen, fällt Dir sicher nicht schwer:
Code:
$ for proc in /proc/[0-9]*; do echo -e "\n$(basename $proc)  /  $(cat $proc/cmdline | tr '\0' ' ')"; cat $proc/status | grep -E 'Vm(Si|RS)'; done

1  /  init
VmSize:     1448 kB
VmRSS:       368 kB

1000  /  dropbear -p 22
VmSize:     1124 kB
VmRSS:       416 kB

1049  /  nmbd -D -o -H /tmp/flash/samba/lmhosts
VmSize:     1500 kB
VmRSS:       932 kB

...
 
Zuletzt bearbeitet:
kriegaex schrieb:
Update: Ich habe Dir etwas gebastelt, mit dem Du alle Prozesse abfragen kannst.
Man könnte meinen du wirst dafür bezahlt :lol:
Danke für die Zeilen, spart mir etwas Zeit ! Habe dir gerade per Mail meine Build-Config geschickt.

Werde mir gleich ein kleines Script zum Beobachten der Prozesse schreiben. Gerade eben hat die Box wieder ein Reboot gemacht, das geht mir gewaltig auf den Keks.
 
Und du hast das wirklich nur mit aktueller Firmware und dsmod? Und mit gleicher Firmware ohne dsmod rebootet die Box nicht? Sicher?

MfG Oliver
 
olistudent schrieb:
Und du hast das wirklich nur mit aktueller Firmware und dsmod? Und mit gleicher Firmware ohne dsmod rebootet die Box nicht? Sicher?
Hier war ich tatsächlich beim Beschreiben etwas unpräzise. Mit dsmod 26-15 und gleicher config lief es stabil, mit 26-15.1 nicht mehr. Ich habe aber die .37 ohne dsmod noch nicht getestet, weil das ja jedes Mal bedeutet, dass ich die Box mehrere Stunden laufen lassen muss, bis der Fehler auftritt.

Ich werde jetzt erstmal die Prozesse beobachten. Wenn ich daraus nicht schlauer werde, werde ich wirklich mal die originale Firmware drüberbügeln. Hast du was spezielles in Verdacht oder tritt der Fehler auch bei Leuten ohne dsmod auf ?
 
Hast du bei ds26-15 auch 29.04.37 verwendet? Von regelmäßigen Abstürzen höre ich eigentlich nur in Verbindung mit DSL- oder WLAN-Problemen.

MfG Oliver
 
Außer VirtualIP-CGI fällt mir nichts Besonderes in Deiner .config auf. Verwendest Du das noch im Zusammenhang mit STunnel und/oder Matrixtunnel? Du hast ja beide in der FW. Daß VirtualIP da Probleme macht, höre ich immer wieder. Aber sonst habe ich keinen schlauen Einfall aus der Ferne.
 
olistudent schrieb:
Hast du bei ds26-15 auch 29.04.37 verwendet? Von regelmäßigen Abstürzen höre ich eigentlich nur in Verbindung mit DSL- oder WLAN-Problemen.
Nein, bei der ds26-15 hab ich noch die .33 verwendet, also nichts von Hand "reingehacked".

kriegaex schrieb:
Außer VirtualIP-CGI fällt mir nichts Besonderes in Deiner .config auf. Verwendest Du das noch im Zusammenhang mit STunnel und/oder Matrixtunnel? Du hast ja beide in der FW. Daß VirtualIP da Probleme macht, höre ich immer wieder. Aber sonst habe ich keinen schlauen Einfall aus der Ferne.
Matrixtunnel wird momentan bei mir nicht verwendet, Stunnel verwende ich im Client-Modus für den Push-Service und für die DynDNS Updates. VirtualIP verwende ich um eth0:1 für den externen SSH Zugriff per Dropbear anzulegen.

Ich lasse mein Script für die Prozess-Beobachtung jetzt mal laufen und teile euch die Ergebnisse im Laufe des morgigen Tages mit.
 
Hi Leute,
ich weis nicht ob das Problem hier noch aktuell ist, aber ich habe mit meiner Box das gleiche Problem !
Ich habe jetzt jedoch rausgefunden, dass der Prozess des UpnP Daemons (igdd) nach einiger Zeit mehrmals geöffnet ist und auch mächtig Speicher verbraucht (gerade eben erst wieder 82,3MB Swap).
Ich habe diesen dann einfach mal mit [killall igdd] "gekillt" und danach einmal mit igdd neu gestartet. Siehe da, es wird nur noch 413kb Swap belegt.
Ich werde jetzt mal testen, ob es an "Sicherheitseinstellungen ändern über UpnP erlauben" liegt oder allgemein an UpnP Portfreigaben. Wie schon erwähnt ist das Problem an meiner anderen Box mit identischer Konfiguration (allerdings ohne UpnP Freigaben im Netz ohne Probleme).
Da ich die Portfreigaben über UpnP benutze, möchte ich diesen Dienst gerne weiter laufen lassen, also müsste ich mir diesbezüglich was überlegen.

MICHA
 
Ein wertvoller Hinweis, ich wollte mir das sowieso mal anschauen. Aber zur Analyse brauche ich eine serielle Konsole, die ich nicht habe oder ein nfsroot, das bei mir noch nicht funktioniert. Letzteres wird mir, wenn es mal geht, helfen, nicht wegen jeder Änderung einer Skriptzeile, deren Ausgabe ich nicht sehen kann, neu zu flashen. Sobald das mal läuft, debugge ich das. Sag Bescheid, ob es ohne igdd besser geht.
 
kriegaex schrieb:
Ein wertvoller Hinweis, ich wollte mir das sowieso mal anschauen.
Die UPNP Port-Freigabe ist auch bei mir aktiv.

Eine 9-stündige Beobachtung hat erstmal folgendes ergeben:

Code:
 ------ MEM INFO  -  Tue Jul 17 03:01:59 CEST 2007 ------
MemFree:          3072 kB
Buffers:          2672 kB
VmallocTotal:  1048560 kB
VmallocUsed:      2232 kB

 ------ MEM INFO  -  Tue Jul 17 12:22:48 CEST 2007 ------
MemFree:          1736 kB
Buffers:          1700 kB
VmallocTotal:  1048560 kB
VmallocUsed:      2656 kB

Der freie physikalische Speicher ist deutlich innerhalb der Zeit geschrumpft.
Ansonsten keine Auffälligkeiten bei dem von den Prozessen reservierten virtuellen Speicher ! Leider hab ich den physikalischen Speicherbedarf der Prozesse (VmRSS) nicht mitgeschnitten, das läuft aber gerade ...

Ergebnisse werde ich natürlich wieder mitteilen.

Übrigens führt die Box eindeutig bei "vollaufen" des Speichers einen Reboot aus, was ich durch das Öffnen eines großen Files mal provoziert habe. Das ist doch eigentlich auch nicht so Sinn der Sache ?!?!?! Die Speicherverwaltung sollte natürlich ein "Out of Memory" melden und den entsprechenden Prozess beenden, aber bitte nicht das ganze System neu starten.
 
Der OOM-Killer ist im Kernel ausgeschaltet, wenn ich mich nicht irre.

MfG Oliver
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
245,752
Beiträge
2,239,120
Mitglieder
372,936
Neuestes Mitglied
Lola2024
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.