"No buffer space available" nach einer Woche Uptime

[µRaCoLi]

Nachdem meine Box ca. ne Woche läuft, lahmt sie und wenn ich sie anpinge, habe ich viele verlorene Pakete.
Also habe ich mich mal eingeloggt und ein paar Befehle eingetippt:

/var/mod/root # traceroute heise.de
traceroute: heise.de: Unknown host
/var/mod/root # traceroute 193.99.144.80
traceroute to 193.99.144.80 (193.99.144.80), 30 hops max, 38 byte packets
 1 traceroute: sendto: No buffer space available
/var/mod/root # cat /proc/meminfo
MemTotal:        30316 kB
MemFree:          2140 kB
Buffers:          2988 kB
Cached:          10404 kB
SwapCached:          0 kB
Active:           8708 kB
Inactive:         8660 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        30316 kB
LowFree:          2140 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:           8436 kB
Slab:             7532 kB
CommitLimit:     15156 kB
Committed_AS:     6176 kB
PageTables:        252 kB
VmallocTotal:  1048560 kB
VmallocUsed:      2900 kB
VmallocChunk:  1044364 kB
/var/mod/root # ping 193.99.144.80
PING 193.99.144.80 (193.99.144.80): 56 data bytes
64 bytes from 193.99.144.80: seq=1 ttl=240 time=87.497 ms
64 bytes from 193.99.144.80: seq=2 ttl=240 time=75.232 ms
64 bytes from 193.99.144.80: seq=3 ttl=240 time=102.120 ms
64 bytes from 193.99.144.80: seq=4 ttl=240 time=49.257 ms
64 bytes from 193.99.144.80: seq=5 ttl=240 time=100.864 ms
64 bytes from 193.99.144.80: seq=6 ttl=240 time=76.030 ms
64 bytes from 193.99.144.80: seq=7 ttl=240 time=50.847 ms
64 bytes from 193.99.144.80: seq=8 ttl=240 time=82.349 ms
ping: sendto: No buffer space available

Nach einem Reboot ist alles wieder normal.
Achso, der Load ist auch normal.

 

[rannseier]

Das kenn ich von virtuellen Servern, da läuft dann othersockbuf voll.

 

[coprophiliac]

Habe dasselbe Problem hier schon einmal angefragt. Hat jemand schon eine Lösung oder einen Ansatz wie man das Vollaufen des Buffers verhindern kann ?
Ich muss wenn ich den Fehler rechteitig erkenne die Box neustarten - z.B. einfacher reboot über ssh. Wenn man zulange wartet nimmt die Box überhaupt Verbindungen mehr an und man muss selber den Schalter betätigen.
Habe noch einen etwas älteren Freetz Build auf einer W701V (29.04.59-freetz-devel-2462M)

/var/mod/root # ping 194.25.2.129
PING 194.25.2.129 (194.25.2.129): 56 data bytes
ping: sendto: No buffer space available

 

[doppelfritz]

also wenn das Problem immer nach 1 Woche auftritt, dann wäre doch folgendes eine Lösung: Man lässt die Box z.B. alle 3 Tage oder jeden Tag automatisch um 4 Uhr nachts rebooten und schon ist das Problem umgangen. Hier die zugehörigen Codeschnipsel, die in die debug.cfg eingefügt werden müssen um das Gewünschte zu erreichen:

await() {
  local day=$((60*60*24))
  sleep $(( ($(date -d $(date +%m%d$1%Y) +%s) - $(date +%s) + $day) % $day ))
}
(
  sleep 120; await 0400;
  reboot;
) &

lässt die Box jeden Tag um 4 Uhr morgens rebooten

await() {
  local day=$((60*60*24))
  sleep $(( ($(date -d $(date +%m%d$1%Y) +%s) - $(date +%s) + $day) % $day ))
}
(
  sleep 259200; await 0400;
  reboot;
) &

lässt die Box alle 3 Tage um 4 Uhr morgens rebooten.

Wenn der Reboot alle X Tage sein soll, dann muss die Zahl hinter dem 2. Sleep nach folgendem Muster errechnet werden: 60*60*24*X

Wenn der Reboot nicht um 4 Uhr passieren soll muss die Zahl hinter dem 2. await nach dem Muster HHMM angepasst werden.

Der Schnippsel stammt aus dem Wiki: http://wiki.ip-phone-forum.de/gateways:avm:howtos:mods:regelmaessiger_neustart

 

[cuma]

Cron scheint einfacher zu sein. Aber das behebt das Problem auch nicht wirklich

 

[coprophiliac]

Mhm, Da ich evtl. noch andere Dienste wie OpenVPN auf der Box nutzen möchte und die IP eigentlich bei KD über längere Zeit schön statisch ist wollte ich das nicht über Reboots der Box in den Griff bekommen. Trotzdem danke für die Hilfestellung - werde ich auf jeden Fall versuchen zu nutzen wenn ich es sonst nicht andersweitig in den Griff bekomme.
Die Reboots treten nicht immer in den gleichen Zeitabständen auf und ich vermute besonders viele zu verwaltende Verbindungen der angeschlossenen 4 Clients bringen sie zu Spitzenzeiten aus dem Takt. Ich tippe daher erstmal auf Speicherverbrauch durch zuviele offene Socket Verbindungen.

Den doch schon etwas älteren Fritz-Trunk werde ich demnächst durch einen neuen Build ersetzen.
Leider klappte das schonmals zwischenrein nicht auf die schnelle weil die Konfiguration danach nicht mehr zurückgespielt werden konnte.

 

[cuma]

Um deine Vermutung zu überprüfen könntest du rrdstats nutzen

 

[coprophiliac]

Ist im alten image leider noch nicht verfügbar gewesen. Ins neue habe ich es eingebaut aber bis jetzt noch keine Zeit gehabt das zu Flashen.

 

[Darkyputz]

@cuma...wie kann da rdstats helfen?

 

[cuma]

Zum schauen ob der Arbeitsspeicher voll ist