Absturz nach Update: Can't connect to localhost:7072

[budy]

Hm, in /var/log/messages ist die letzte Nachricht um 14:42, also weit vorher und auch nicht spannendes:

Code Auswählen Erweitern


Feb 23 14:42:14 HomeServer rsyslogd-2007: action 'action 13' suspended, next retry is Thu Feb 23 14:42:44 2017 [try http://www.rsyslog.com/e/2007 ]


In /var/log/syslog steht in dem Zeitfenster und auch davor gar nichts.
Und kern.log hat Einträge vom 03.12.16!? Da sind auch keine archivierten kern.logs

Dann solltest du dir mal die Logging Optionen des rsyslogd ansehen. Ggf. sind die so eingestellt, dass gar kein Log erzeugt wird, oder dass es nur auf die Konsole geloggt wird - immerhin handelt es sich ja um ein System welches naturgemäß so wenig wie möglich auf die SD Karte schreiben soll und da haben die Autoren ggf. daran gedreht.

Gruß,
Stephan

[HansDampfHH]

So, da bin ich mal wieder. Neustart bzw. Absturz von FHEM kommt nicht mehr so oft vor, von daher erst heute ein Feedback.
Ich habe das kern.log aktiviert und in letzter Zeit "nur" zwei Abstürze gehabt. Exakt zur gleichen Zeit kommt folgender Eintrag im kern.log:

Code Auswählen Erweitern


Mar  5 07:37:52 HomeServer kernel: [1085441.844492] perl[17906]: segfault at 40000a56d0fc ip 00007f7b938bd807 sp 00007ffd299e0dc0
Mar 10 13:43:01 HomeServer kernel: [1539346.132409] perl[24417]: segfault at 3f853211c740 ip 00003f853211c740 sp 00007ffe7259b3c8


Hat jemand dazu erhellende Hinweise?

[Wernieman]

Wenn der oem-Killer zuschlägt, kann so etwas vorkommen.
Steht etwas im Syslog?

Was mir noch einfällt:
Du hattest "gepingt" .. wieviele Ping-Prozesse läst Du zu?

(P.S. welche Pi Version mit wieviel RAM)

[HansDampfHH]

Ping wird default ausgeführt, also wohl ping_count 4.
Ist ein Intel NUC mit Debian und einem 4GB Riegel.
Im syslog steht nichts weiter zur fraglichen Uhrzeit.

[Wernieman]

Was mich dann wundert .. wieso hast Du "Out Of Memory" ... was hast DU alles "auf der Kiste" laufen?
Kannst DU mal bitte per htop gucken, wie die Mem belastung ist (besser währe top, aber schwieriger zu lesen)

[HansDampfHH]

Das ist es ja, gibt keinen Grund dafür. Die Auslastung liegt durchgehend bei 1-3%CPU.
Da ich kein Linux-Profi bin kann ich mit der Mem Angabe nicht viel anfangen.
Soweit mir bekannt nutzt Linux doch eh immer den gesamten Ram bzw. gibt den nicht gleich frei.

Welche Angabe kann ich Dir geben?
Unter Mem steht 1018/385 bzw. für die perl-Prozesse (fhem) jeweils 3,5%.

[budy]

Also, ich habe auch schon mal sporadisch den ganzen Speicher voll gehabt. Auf meinem pi liefen bis vor kurzen aber auch noch ein paar andere Services wie Nextcloud und MariaDB mit. Die habe ich inzwischen mal woanders hin migriert... Wenn der Speicher sehr schnell, sehr plötzlich dermaßen voll geht, dass nix mehr funktioniert oder der OOM-Killer zuschlägt, dann wird es sehr schwer werden das herauszufinden.

Dazu müsste man das System sehr genau beobachten, wofür man normalerweise die Zeit gar nicht hat.
Wichtig ist schon mal, dass das Sytem im Normalzustand nicht swappen sollte. Das war bei meinem pi vorher der Fall, auch wenn es sich nicht so um 128MB gehandelt hatte.

Jetzt läuft auf meinem pi nur noch FHEM, Hombrige und Alexa-FHEM, sowie ein Apache als Reverse-Proxy... seit dem swappt der pi nicht mehr.
Ich würde mal wetten, dass auf dem NUC - der ist ja deutlich größer, als ein pi, noch mehr als nur FHEM läuft... oder?

Gruß,
Stephan

[Wernieman]

htop zeigt Dir auch die Speicherauslastung.

Ansonsten bei htop nach Speicher sortieren lassen und gucken, wer (im Normalfall) was braucht.
btw: Hast Du eine DB am laufen?

[HansDampfHH]

Das sieht alles nicht ungewöhnlich aus. Wie gesagt, mem bei den FHEM Prozessen 3,5%...da kommt nicht viel zusammen.
Eine DB läuft nicht und auch sonst nichts weiter. Nun ist es wieder stabil, tritt eben sehr sporadisch auf.

Monit läuft nun und startet bei Bedarf FHEM umgehend neu. Nicht schön, aber so ist das zumindest keine spürbare Einschränkung.
Darüber bekomme ich eine Email und schau dann immer mal wieder ins Log. Nun passiert das aber auch nicht mehr täglich.

[HansDampfHH]

Okay, ein weiteres Feedback.
Ich habe nun noch weitere Geräte eingehängt, die ich anpinge und das PRESENCE Modul nutze.
Das sind ein paar Handys, TV, HTPC, PS4 und somit nun insgesamt 10 Devices.

Seit dem ich die letzten 3 Geräte eingehängt habe friert das System ständig ein.
Wenn Devices nicht anwesend sind wird j ständig gepingt. Das flutet wohl das System:

Code Auswählen Erweitern


TCP: Possible SYN flooding on port 7072. Sending cookies.  Check SNMP counters.


Kann mir jemand vielleicht verraten an welcher Schraube ich drehen könnte / müsste?
Da ich schon relativ zeitnah wissen möchte welche Devices HOME sind möchte ich keinen großen Intervall beim pingen einstellen.

Lediglich ping_count habe ich auf 2 gestellt, das hat aber nichts gebracht.

[dev0]

Du kannst versuchen die maximal erlaubte Anzahl ausstehender syn requests zu erhöhen. Such mal nach: net.ipv4.tcp_max_syn_backlog

[HansDampfHH]

Also ein "echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog" hat bisher wunder gewirkt.
Konnte alle Devices wieder anpingen und FHEM ist nun seit fast 3 Tagen stabil. Bisher also vielleicht der richtige Hinweis

[Mitch]

Ich hänge mich mal hier dran.

Hab seit ein paar Tagen auch ständig Abstürze und habe gerade mal ein bisschen geforscht.
Nachdem ich den Loglevel hochgenommen habe, habe ich festgestellt, dass fhem mit Out of memory! abstürzt.

Das System ist ein NUC mit 8GB, darauf läuft fhem, Alexa, Homebridge, UnifiController mit MongoDB, Apache2, Monit und eine Backupsoftware.
Top und htop zeigen eine normale Auslastung: 1GB von 9GB genutzt.
UnifiController braucht ca 5.3% RAM, Apache 2.1% und fhem 2.0%, also alles im Rahmen.

Ich habe auch schon das PRESENCE Module in Verdacht, da ich da drei Devices dazu genommen habe.

Könnte die tcp_max_syn_backlog Geschichte bei mir helfen?

[Wernieman]

Kannst Du den Memverbrauch mitloggen?

[dev0]

@Mitch: Nein, tcp_max_syn_backlog hat nichts mit oom zu tun.