24h Neustart der Box

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Leute, ihr tastet im Dunklen meiner Meinung nach. Ich glaube wenig, dass DECT direkt ein Verursacher für Reboots ist. Indirekt könnte es schon sein. Defacto ist, dass irgendwo entweder bei AVM oder im OpenSource-Kernel (vielleicht nur in Zusammenhang mit AVM-Hardware) ein Fehler bei der RAM-Verwaltung existiert. Dieses Verhalten kennt man schon seit Jahren bei den Fritz!Boxen: Wenn es viele Anwendungen/Dienste auf der Box laufen und es mit dem RAM etwas knapp wird, versagt die Speicherverwaltung in bestimmten Fällen und die Box rebootet/enfriert.
Ich vermute hierbei eine reine Priorisierung/Geschwindigkeitsfrage: Wächst der RAM-Bedarf schneller als es verwaltet werden kann, sodass die Speicherverwaltung nicht "hinterher kommen" kann, so kommt es zum Speicherüberlauf. Und dies wird desto wahrscheinlicher und desto schneller passieren, je mehr, je größere und je priorisierungsstarke Prozesse am RAM-Limit "kratzen".

MfG
 
Und vorher ohne Dect ist das auch aufgetreten? Hast du ATA-modus aktivert? Ist dein Kernel ersetzt?
@hermann72pb: Irgendwann findet man die Kerze.. Es tritt halt nicht bei jedem auf, und der RAM-verbrauch steigt kontinuierlich
 
cuma schrieb:
Und vorher ohne Dect ist das auch aufgetreten? Hast du ATA-modus aktivert? Ist dein Kernel ersetzt?
@hermann72pb: Irgendwann findet man die Kerze.. Es tritt halt nicht bei jedem auf, und der RAM-verbrauch steigt kontinuierlich
Zum Vergrößern anklicken....

Ich geh mal davon aus, du meinst mich. Ja es liegt sicher nicht am DECT. Ich hatte vorher auch das Problem. ATA Modus heißt das alles über das DSL Modem läuft? Wenn ja dann nein :) Ich nutze die Box nur als Router. Habe einen SHDSL NT als Abschluss an dem "Ethernet" rauspurzelt was bei mir auf den Port 1 der Box läuft.
 
Nein, ata-modus meint deine Konstellation.
 
Dann sei es so! ATA-Modus bzw. Router mit PPPoE Auth.
 
Hallo Zusammen,

ich kenne das Problem auch. Bei mir laufen zwei W900V mit identischem Image (34.04.70) OpenVPN, DNSmasq.

Box 1:
- ISDN
- Dect aus
- kein Voip
- 3 routing Einträge in der rc.costum

Box 2:
- Analog
- Dect ein
- Voip

Beide Boxen nutzen Swap, Box 1 startet ca jeden zweiten Tag neu, das Problem bestannt auch bei älteren Images. Ich vermute bei dem Problem eher einen zusammenhang mit dem ISDN Anschluss. Der Reboot tritt eher auf wenn das Netz intensiv genutzt wird.

Grüße, Jan Gerrit
 
Telefonie ist auch ein einfacher möglicher Grund. Den ndas hab ich grad hier erlebt bei einem Versuch, nach draussen zu Wählen. Das Telefon an sich war aber per FON1 an der Box, ein weiteres - zu dem Zeitpunkt ungenutzt und nur angemeldet - per DECT angeschlossen.

War jetzt ohne es wirklich verifizieren zu können des mindestens 2. Mal bie dem Versuch, nach draussen zu wählen.

Allerdings muss die Box vorher eine unklare Zeit laufen. Macht die Fehlerfindung eher problematisch leider.

edit:

Ich vermute übrigens nicht den Speicher, sondern eher die CPU. Bei mir auf der box fand sich vor dem Absturz ein gravierender Anstieg der CPU-Last auf merh als 50% von vorher durchgehend weniger als 10%
 
Zuletzt bearbeitet:
Ursache bei mir ist auf jedenfall der RAM, wie im bild von Post #4 zu sehen. Und das passiert meist wenn niemand hier ist. CPU steigt dann auch ganz kurz vorher an, was ist aber nicht für die Ursache halte. Als Telefonverbindung habe ich nur VoIP und dazu 1xISDN und 2xDECT Telefone. Telefoniert wird auch nicth soo viel.
@starmagoo: Meine Box ist auch so angeschlossen, brauche aber keine Authentifikation. Hast du deinen Kernel ersetzt?

Achso, und ATA bedeutet eigentlich "Analog-Telefon-Adapter", was im ursprünglichen Sinne nichts mit DSL hatte... Wie kam es denn zu der Bezeichnung?
 
Silent-Tears schrieb:
Ich vermute übrigens nicht den Speicher, sondern eher die CPU.
Zum Vergrößern anklicken....
Das würde ich auch eher tippen. Allerdings, wenn RAM nah am Limit ist. Denn alleine hohe Prozessorlast darf die Box nicht zum reseten bringen, sonst hätten wir alle hier nur Dauerreboots.

Ich hatte mächtig ähnliche Probleme mit einer Reihe 7050-Boxen kurz vor deren Aussterben. Damals hat AVM aus der armen 7050 die letzten Säfte ausgepresst, sodass sie relativ hart am Limit war, ähnlich wie die 7170 jetzt. Die Ursache war zwar nie gefunden, einige Beobachtungen und "kosmetische" Workarrounds hatten aber teilweise geholfen Probleme zu minimieren.

Aufgetreten waren die Probleme meistens, wenn die Box was richtig zu tun hatte. Typisches Beispiel: Zweiter Anruf während des ersten laufenden Gespräches. Die Box "starb" entweder sofort oder hatte an Spätfolgen zu leiden.

Abhilfe wurde dadurch geschafft, dass ich OpenVPN (übrigens im RAM sitzend, wegen Platzmangel) nur bei Bedarf startete.
Ferner hatte ich etwas an den Einstellungen von dropbear geschraubt (ist schon länger in FREETZ drin), um die Folgen von DoS-Attaken auf Port 22 etwas zu minimieren.

Wenn man alle Maßnahmen analysiert, kann man im allgemeinen sagen, dass es darum ging, die Box zu entlasten: einerseits RAM-mäßig, aber auch Prozessorlast-mäßig, damit sie die "Lastspitzen" gesund überlebt.

Hier ist die Situation natürlich dadurch verschärft, dass der RAM-Bedarf nachweislich und kontinuerlich steigt. Kommt dazu noch die Lastspitze, so rebootet die Box.

MfG
 
hermann72pb schrieb:
Das würde ich auch eher tippen. Allerdings, wenn RAM nah am Limit ist. Denn alleine hohe Prozessorlast darf die Box nicht zum reseten bringen, sonst hätten wir alle hier nur Dauerreboots.
Zum Vergrößern anklicken....


Ich spreche allerdings von ner 7240 mit 16MB Flash und 64MB RAM. Ist also eher ein unkritischerer Fall, denke ich. Dazu gibt es Swap auf nem Schnellen USB-Stick. RAM-Mangel gibt es da nicht.
 
Ja, bei mir sind es ja auch 64MB RAM. Nur mit welchem Befehl oder Tool kann ich feststellen wodurch der RAM belegt ist? Bei "top" siehts alles normal aus
 
Hab jetzt den Verursacher bei mir gefunden. Es handelt sich um RRDstats in Verbindung mit DigiTemp. Auch nach beenden dessen und entladen der Module wird bei mir der Speicher nicht freigegeben. Möglicherweise trifft dies nur auf die 7270 mit dem neuen Kernel zu.

Könnt die mit Problemem und die mit RRdstats incl Digitemp (die gleichen?) bitte folgende Ausgabe posten:
Code: 
echo -n " slab size-32: $(((`cat /proc/slabinfo |grep "size-32     "|tr -s " "| cut -d " " -f 2,4|sed 's/ /*/'`)/1048576)) MB, uptime ";uptime|sed 's/.* up //;s/,.*//'
 slab size-32: 10 MB, uptime 13:53

Möglich Probleme:
-ständiges Schreiben auf USB
-ständiges Abfragen der Werte mit DigiTemp (ein Sensor kann 5 Sekunden benötigen)
-Fehler in der Verwaltung der PIDs, es werden viele verbraucht
-DigiTemp
-...?

Mein Dank geht an Oli und Ralf für die Hilfe bei der Fehlersuche!
 
Zuletzt bearbeitet:
Meine Box hat sich vor paar Minuten neugestartet und diesmal sind ein paar Log Einträge auf meinem syslog server aufgetaucht. Eventuell kann jemand damit etwas anfangen...

Code: 
Mar  9 10:49:37 192.168.178.1 kernel: printk: 36 messages suppressed.
Mar  9 10:49:37 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:37 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:37 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:37 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:37 192.168.178.1 kernel: [<9404c49c>] page_cache_read+0x64/0xf8
Mar  9 10:49:37 192.168.178.1 kernel: [<9404c718>] filemap_nopage+0x1e8/0x40c
Mar  9 10:49:37 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:37 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:37 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:37 192.168.178.1 kernel:
Mar  9 10:49:37 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:37 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:37 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:37 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:37 192.168.178.1 kernel: [<94053094>] __do_page_cache_readahead+0xf4/0x2b8
Mar  9 10:49:37 192.168.178.1 kernel: [<9404c694>] filemap_nopage+0x164/0x40c
Mar  9 10:49:37 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:37 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:37 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:37 192.168.178.1 kernel:
Mar  9 10:49:37 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:37 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:37 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:37 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:37 192.168.178.1 kernel: [<9404c49c>] page_cache_read+0x64/0xf8
Mar  9 10:49:37 192.168.178.1 kernel: [<9404c718>] filemap_nopage+0x1e8/0x40c
Mar  9 10:49:37 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:37 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:37 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:37 192.168.178.1 kernel:
Mar  9 10:49:37 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:37 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:37 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:37 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:37 192.168.178.1 kernel: [<94053094>] __do_page_cache_readahead+0xf4/0x2b8
Mar  9 10:49:37 192.168.178.1 kernel: [<9404c694>] filemap_nopage+0x164/0x40c
Mar  9 10:49:37 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:37 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:37 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:37 192.168.178.1 kernel:
Mar  9 10:49:37 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:37 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:37 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:37 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:37 192.168.178.1 kernel: [<94053094>] __do_page_cache_readahead+0xf4/0x2b8
Mar  9 10:49:37 192.168.178.1 kernel: [<9404c694>] filemap_nopage+0x164/0x40c
Mar  9 10:49:37 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:37 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:37 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:38 192.168.178.1 kernel:
Mar  9 10:49:38 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:38 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:38 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:38 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:38 192.168.178.1 kernel: [<9404c49c>] page_cache_read+0x64/0xf8
Mar  9 10:49:38 192.168.178.1 kernel: [<9404c718>] filemap_nopage+0x1e8/0x40c
Mar  9 10:49:38 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:38 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:38 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:38 192.168.178.1 kernel:
Mar  9 10:49:38 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:38 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:38 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:38 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:38 192.168.178.1 kernel: [<94053094>] __do_page_cache_readahead+0xf4/0x2b8
Mar  9 10:49:38 192.168.178.1 kernel: [<9404c694>] filemap_nopage+0x164/0x40c
Mar  9 10:49:38 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:38 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:38 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:38 192.168.178.1 kernel:
Mar  9 10:49:38 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:38 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:38 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:38 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:38 192.168.178.1 kernel: [<94053094>] __do_page_cache_readahead+0xf4/0x2b8
Mar  9 10:49:38 192.168.178.1 kernel: [<9404c694>] filemap_nopage+0x164/0x40c
Mar  9 10:49:38 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:38 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:38 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:38 192.168.178.1 kernel:
Mar  9 10:49:38 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:38 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:38 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:38 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:38 192.168.178.1 kernel: [<9404c49c>] page_cache_read+0x64/0xf8
Mar  9 10:49:38 192.168.178.1 kernel: [<9404c718>] filemap_nopage+0x1e8/0x40c
Mar  9 10:49:38 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:38 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:38 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:38 192.168.178.1 kernel:
Mar  9 10:49:38 192.168.178.1 kernel: Call Trace:
Mar  9 10:49:38 192.168.178.1 kernel: [<9400d824>] dump_stack+0x8/0x34
Mar  9 10:49:38 192.168.178.1 kernel: [<9404f4fc>] out_of_memory+0x90/0x214
Mar  9 10:49:38 192.168.178.1 kernel: [<9405099c>] __alloc_pages+0x224/0x2f0
Mar  9 10:49:38 192.168.178.1 kernel: [<94053094>] __do_page_cache_readahead+0xf4/0x2b8
Mar  9 10:49:38 192.168.178.1 kernel: [<9404c694>] filemap_nopage+0x164/0x40c
Mar  9 10:49:38 192.168.178.1 kernel: [<9405ace8>] __handle_mm_fault+0x184/0xae4
Mar  9 10:49:38 192.168.178.1 kernel: [<94011b64>] do_page_fault+0x104/0x390
Mar  9 10:49:38 192.168.178.1 kernel: [<94007108>] ret_from_exception+0x0/0x14
Mar  9 10:49:38 192.168.178.1 kernel:
Mar  9 10:51:26 192.168.178.1 chronyd[1200]: chronyd version 1.23 starting
Mar  9 10:51:26 192.168.178.1 chronyd[1200]: Initial txc.tick=10000 txc.freq=0 (0.00000000) txc.offset=0 => hz=100 shift_hz=7
Mar  9 10:51:26 192.168.178.1 chronyd[1200]: set_config_hz=0 hz=100 shift_hz=7 basic_freq_scale=1.28000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000
Mar  9 10:51:26 192.168.178.1 chronyd[1200]: Linux kernel major=2 minor=6 patch=19
Mar  9 10:51:26 192.168.178.1 chronyd[1200]: calculated_freq_scale=0.99902439 freq_scale=0.99902439
Mar  9 10:51:27 192.168.178.1 chronyd[1200]: System's initial offset : 0.000643 seconds slow of true (slew)
Mar  9 10:51:28 192.168.178.1 chronyd[1200]: Could not send to 212.13.194.87 : Bad file descriptor
Mar  9 10:51:29 192.168.178.1 chronyd[1200]: Could not send to 212.13.194.87 : Bad file descriptor
Mar  9 10:51:30 192.168.178.1 chronyd[1200]: Could not send to 212.13.194.87 : Bad file descriptor
Mar  9 10:51:33 192.168.178.1 dropbear[1535]: Running in background

Kurz vorher habe ich mich mit SSH verbunden und ab 10:51 startet die Box gerade neu...
 
cuma hat schon festgestellt, daß bei ihm einer der slab-Werte kontinuierlich ansteigt. Schau Dir mal den Beitrag vor Deinem an. Das out_of_memory in Deinem Stack-Dump paßt damit zusammen, daß der Speicher irgendwann aufgebraucht wird.

Hast Du auch etwas am USB abgeschlossen?
 
Ok RRDstats hab ich jetzt einfach deaktiviert. Ob was am USB hängt? öhm... ja :cool: mein ganzes Freetz läuft über den USB (USBroot). Zugriff is also immer und ständig. Könnte natürlich ein Problem sein. Ich werd auch bei gelegenheit mal den USB-Stick tauschen bzw mal das ganze neu aufziehen...
 
Vermutlich sind weniger die USB Massenspeicher das Problem, da diese vom AVM schon lange unterstützt werden und auch USB-Root schon länger existiert und noch keine Probleme in dieser Art damit berichtet wurden.
 
Vielleicht ist es aber die Art des Sticks bzw. die schreib und lese geschw. Hab momentan ein Noname Werbegeschenk dran... :blonk:
 
Also am USB Stick bzw. daran das ich alles über USB-Root laufen habe scheint es wohl nicht zu liegen. Ich habe mal alle nicht genutzten Dienste auf der Kiste deaktiviert und siehe da sie läuft sogar 3 tage durch. Danach musste ich neustarten. Das ganze wäre wohl auch noch länger gegangen.

Was derzeit noch läuft ist callmonitor, webcfg, USBroot, syslogd, avm-firewall.
Zu Zeiten des regelmäßigen Neustarts der Box lief unter anderem dropbear, RRDstats, privoxy, tor, virtualip, checkmaild, openntpd, vsftpd, inotify-tools, inadyn-mt.

Eines dieser Dienste führt zum Neustart. Da ich nicht alle durchtesten mag und will ;) schalte ich alles was ich brauche bei bedarf zu. Das wäre dann meine Notlösung :lamer:
 
Dann lass doch mal RRDstats, privoxy und tor aus. Darauf würde ich jetzt tippen.

MfG Oliver
 
Privoxy und Tor (vor allem Tor) sind meine Kandidaten. Denn nahezu alles andere läuft hier auch.
Die Kombination Privoxy/Tor hat meine 7170 ziemlich häufig rebooten lassen.
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 779 (Mitglieder: 41, Gäste: 738)

Neueste Beiträge

Statistik des Forums

Themen
246,149
Beiträge
2,246,940
Mitglieder
373,664
Neuestes Mitglied
Nicki1001
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück