Warum beendet sich FHEM immer mal wieder ? - Jemand anders auch betroffen ?

Begonnen von Stargazer, 22 Mai 2017, 20:53:45

Vorheriges Thema - Nächstes Thema

Stargazer

Derzeit ist es auffällig, dass die Energieinstanz von FHEM häufiger ausfällt, als der Wohnungsserver... .
Die Wetterstation wurde heute Morgen um 6 Uhr zuletzt vom Wohnungsserver und dessen Davis Vantage Pro Modul abgerufen.

Jetzt ist die Frage, ob sich da doch irgendwas überschneidet.. ?


Markus M.

FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

Stargazer

Hallo zusammen,

das mit der Wetterstation scheint sich irgendwie zu erhärten. Es scheint ein Hardwarefehler zu sein.
Denn wenn ich sie, wie sonst nach so einem Defekt, einfach kurz Stromlos schalte, damit sich die Station
neu einbuchen kann, kommt sie nicht mehr ins Netz zurück. Die IP wird unter dem Router als "Ungenutzte
Verbindung" deklariert. Ich hatte auf dem Wohnungsserver die Station nochmal gelöscht und neu angelegt.
Auch hier kommen keine Daten an. Auf der App ebenfalls. Hoffentlich war's das und es lag trotzdem an
diesem "Wackelkandidaten". Ich werde das im Auge behalten und berichten.

Ich habe das bereits dem Service gemeldet. Wird wohl auf einen Tausch herauslaufen.

VG

André

PS.: Wie aktiviere ich das Stacktrace und was macht das ?

Markus M.

Such mal in der commandref und im Forum, bin gerade unterwegs.
Das sagt dir warum FHEM abstürzt.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

rudolfkoenig

@Markus M: stacktrace zeigt nach einer "PERL WARNING" Meldung von FHEM, welches Modul diese Meldung ausgeloest hat. Aktivieren kann man es mit "attr global stacktrace". Wenn man keine Meldungen im FHEM-Log findet, dann hilft stacktrace auch nicht.

@Stargazer: ich empfehle immer noch
ZitatFHEM in screen mit  "attr global logfile -" zu starten.

@schka17: Ein Speicherloch in einem Perl Programm habe ich bisher nur bei Verwendung von XML-DOM Bibliotheken gesehen (da aber oefters), wenn der Autor die (in perl unuebliche) explizite Freigabe des Speichers vergessen hat.

herrmannj

ich erlaube mir hier eine persönliche Erfahrung einzustreuen die ich vor einigen Wochen gemacht habe.

Dazu hatte ich mir eine eigene (fhem) lib vorgenommen und habe mir gedacht, hey, schau mal so im Zuge der Qualitätssicherungen, ob da auch wirklich aller Speicher wieder freigegeben wird. War eher so pro-forma, macht perl ja selber. Etwa eine Stunde später war mir klar das *meine* lib dutzende von Speicherlöchern hatte. Das hätte ich auch nie gemerkt hätte ich nicht aktiv danach gesucht.

vg
joerg


schka17

Zitat von: rudolfkoenig am 24 Mai 2017, 10:45:43
@schka17: Ein Speicherloch in einem Perl Programm habe ich bisher nur bei Verwendung von XML-DOM Bibliotheken gesehen (da aber oefters), wenn der Autor die (in perl unuebliche) explizite Freigabe des Speichers vergessen hat.

XML-DOM Bibliotheken, sorry da verstehe ich nur Bahnhof, wüsste auch nicht wie feststellen kann welches Modul der Verursacher ist. Hab den damaligen Thread grad nochmal rausgesucht
https://forum.fhem.de/index.php/topic,27223.0.html

Wahnsinn, ist bald 3 Jahre her, unzählige updates und Änderungen seither, aber das Problem sowie der workaround immer noch da.



Sent from my iPad using Tapatalk
M: Thinclient x64 Debian | CUL FS20, HMS100WD, HMS100TF, HMS100T, HMS100CO, S300, S555TH | OWServer DS1420, DS18B20, DS2408 | RFXCOM UVN128, THWR800, THGR228N,RTGR328, PCR800 |Jeelink PCA301 EC3000|CUNO+IR|HMLAN|HMUSB|CUL433 Somfy|mySensors|espEasy
S1:Raspberry mit BPM810, Jeelink EC3000

Stargazer

Hallo zusammen,

es scheint derweil wirklich so zu sein, dass es an der Davis Station liegt.
Ich hatte das ganze jetzt mal einen Tag komplett vom Netz genommen und nun wieder aktiviert.
Nun meldete sie sich wieder unter der IP an und ich hatte kurz nochmal das Modul gestartet um zu sehen, ob alles läuft.
Und soweit läuft sie gut. Doch man merkt im Netzwerk, dass, wenn das VantagePro - Modul am laufen ist, die Perfomance etwas einknickt. Also speziell was FHEM angeht. Da braucht es doch länger, eh sich die Browserseite mit FHEM aufbaut.
Das ist schonmal auffällig. Also ist erstmal auf jeder FHEM-Instanz das Modul deaktiviert.

Derweil habe ich eine andere Lösung um an die Daten zu gelangen. Ist zwar etwas am Leben vorbei, aber was will man machen ?

Ich rufe jetzt die WeatherLink Seite im Internet via HTTPMOD-Modul ab und werte diese aus. Wie gesagt...etwas Plem-Plem, aber wenn es nicht anders geht. Ich werde die Station trotzdem weiter im Auge behalten.

Ich habe jedoch noch das Problem, dass er mir in dem HTTPMOD-Modul noch keine Readings erzeugt.
Folgende Auswertung wurde via regex101.com gegengerechnet:

Hier die Attribute:

attr WeatherLink readingsName_Barometer Barometer
attr WeatherLink readingsRegex_Barometer (?s)Barometer.{43}([\d\.]+)


Dazu der Buffer des Moduls im Ausschnitt:
</tr> <tr> <td width="190" class="summary_data">Barometer</td> <td width="170" class="summary_data">1022.2hPa</td> <td width="100" class="summary_data">1024.1hPa</td> <td width="100" class="summary_data">11:02 AM</td> <td width="100" class="summary_data">1022.2hPa</td> <td width="100" class="summary_data">8:12 PM</td> </tr>

Kann da eventuell noch jemand drüber gucken ?
Ich kann keinen Fehler finden. Mit regex101 funktioniert es.


Viele Grüße und besten Dank

André

PS.: Könnte es sein, dass diese Probleme von einer "Inkompatibilität" des VantagePro - Moduls mit einer höheren FHEM Version herührt ?



Wernieman

ZitatDoch man merkt im Netzwerk
Mit Beaduern muß ich immer wieder feststellen, das die Leute "netzwerk" sagen, wenn sie allgemeine Probleme meinen. Netzwerk ist seeeehr vielschichtig. Meinst Du jetzt netzwerkgeschwidigkeit, wie z.B. zum surfen im netz, oder der Zugriff zu Deiner FHEM-Instanz. Ist es der Pi, oder .....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Stargazer


Zitatz.B. zum surfen im netz, oder der Zugriff zu Deiner FHEM-Instanz. Ist es der Pi, oder .....

Derzeit spürt man es in erster Linie auf den beiden FHEM - Instanzen.
Wir haben bei meinen Eltern eine Art "Infoschirm" mit dem originalen 7" Raspi - Touchdisplay installiert.
Läuft dort seit über einem Jahr sehr gut. Dort wird die Dashboard - Seite des Energieservers dargestellt.
Also die FHEM Instanz für die Energie. Diese lädt wesentlich schneller und läuft insgesamt perfomanter.

Ich habe jetzt, seit dem ich das Modul nicht mehr aktiv habe, auch keine weiteren Ausfälle der FHEM - Server
gehabt. Mal sehen ob das so bleibt, wenn die Station weiterhin aktiv im Netzwerk bleibt.
Darum liegt derzeit meine Vermutung einfach an einem Problem mit dem VantagePro - Modul.

VG

André

borsti67

ich klinke mich mal hier ein, weil ich ein ähnliches Problem beobachte, seit ich mein System auf dem Pi Zero laufen habe.
FHEM läuft max. 2-3 Tage durch, dann beendet es sich (und wird durch systemd automatisch wieder gestartet).
Entweder steht gar nichts besonderes im fhem.log vor so einem Abbruch (man sieht also nur an den Start-Meldungen, dass es offensichtlich zuvor beendet wurde) oder es gibt 1000e von "too many open files"-Meldungen, gewöhnlich mit "Accept failed telnetForBlockingFn..." oder auch das SYSSTAT /proc/loadavg nicht öffnen kann...

Auffällig finde ich, dass im syslog KEINERLEI Fehler aufgezeichnet sind (nur dass systemd FHEM wieder startet). Die Kiste wird für nichts anderes genutzt, von daher kann ich auch nicht sehen, ob sich das woanders auswirken würde...

Leider habe ich im Forum schon gelesen, dass dieser "open files"-Fehler schwer aufzuspüren sei? Der einzige nennenswerte Hinweis betraf die Verwendung von lsof und zu viele "CLOSE_WAIT"-Verbindungen. Da wäre für mich die Frage, wie viel ist zu viel bzw. was wäre "normal"?
Ich sehe gerade, dass etliche offene Verbindungen ins fhem.log da sind, und mehr als 30 CLOSE_WAIT im Zusammenhang mit Jabber:
perl    15099 fhem  474w   REG      179,2   646640  244886 /opt/fhem/log/fhem-2018-01.log
perl    15099 fhem  475u  IPv4    1099457      0t0     TCP fhempi.fritz.box:41268->jabberd.***.de:xmpp-client (CLOSE_WAIT)

Letzteres ist merkwürdig, denn ich sende nur wichtige Alarme per MSG über XMPP, das sind max 4 am Tag!

Kann ich das Problem weiter eingrenzen?
cu/2
Borsti
---
FHEM 5.8 auf Synology DS211j (bis 11/17) | FHEM 6.0 auf Raspi Zero W (bis 11/20) | FHEM 6.2 als VM in Synology DS1815+ (ab 11/20)

rudolfkoenig

ZitatAuffällig finde ich, dass im syslog KEINERLEI Fehler aufgezeichnet sind (nur dass systemd FHEM wieder startet).
Ich gehe davon aus, dass wenn man FHEM in einem Terminal startet (z.Bsp. mit screen), etwas mehr zu sehen ist.
Was mir bei Pi Zero direkt einfaellt, ist Speicherknappheit, dabei schiesst Linux gerne den groessten Prozess ab.
Im Terminal wuerde dann sowas wie "Killed" stehen. In FHEM Speicherverschwender zu suchen ist schwierig, ich habe dafuer mal "fhemdebug memusage" gebaut, was in manchen Faellen bei der Lokalisierung des Verursachers helfen kann.

ZitatDer einzige nennenswerte Hinweis betraf die Verwendung von lsof und zu viele "CLOSE_WAIT"-Verbindungen.
Bedeutet, dass die andere Seite die TCP-Verbindung schliessen will, und wartet darauf, dass diese Seite es mitkriegt, und mit close() reagiert. Wenn dieser Zustand laenger als ein paar Millisekunden zu sehen ist, dann ist das ein Programmierfehler, und sollte dem Modulautor gemeldet werden. Sollte aber nicht zu einem Absturz, sondern erst bei ca 1000 solcher "Zombies" zu Problemen beim Oeffnen neuer Verbindungen fuehren. Je nach Modul evtl. auch zu einem erhoehten Systemlast.

borsti67

Speicher ist natürlich gut belegt, das stimmt.
top - 15:47:53 up 34 days,  5:21,  1 user,  load average: 0.27, 0.28, 0.17
Tasks: 106 total,   1 running, 105 sleeping,   0 stopped,   0 zombie
%Cpu0  :  1.8 us,  2.4 sy,  0.0 ni, 95.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    444532 total,   373412 used,    71120 free,    22228 buffers
KiB Swap:  1048572 total,    62432 used,   986140 free.    98012 cached Mem

Bei meinen ersten Experimenten mit dem Pi habe ich aber bei einem OOM immer einen Eintrag im syslog gehabt, daher kann ich mir dies schwer vorstellen.

Der Debug-Befehl von Dir ergibt an oberster Stelle dies:
1. intAt                            535454
   2. modules::FHT                     205428
   3. defs::IM                         191579
   4. Net::XMPP::Namespaces::NS        167969
   5. SIG                              146704
   6. Exporter::Cache                  122328
   7. modules::eventTypes               92364

Hilft das weiter?

Aber: Aus den gestrigen 30 CLOSE_WAIT sind bis heute über 400 geworden!
Ich werde mal BioS' Thread https://forum.fhem.de/index.php/topic,18967.0.html verlinken.

Danke jedenfalls schon mal!
cu/2
Borsti
---
FHEM 5.8 auf Synology DS211j (bis 11/17) | FHEM 6.0 auf Raspi Zero W (bis 11/20) | FHEM 6.2 als VM in Synology DS1815+ (ab 11/20)

BioS

Ahoi borsti,

Ich hab dir schon im anderen Thread geantwortet und jetzt bei mir noch ein bisschen getestet:
Wenn ich Nachrichten per Jabber verschicke, bekomme ich keine CLOSE_WAIT Meldungen.
Ich hab genau eine TCP Verbindung zu meinem Jabber Server und die sollte auch gehalten werden um Nachrichten zu senden und zu empfangen.

Ich würde sagen die "too many open files" Meldung, wie auch dein Absturz von FHEM ist alles Auswirkung und nicht die Ursache.

Probier sicherheitshalber trotzdem mal mein Modul zu deaktivieren, wer weis was mit neueren XMPP Perl Modulen wieder alles kaputt gegangen ist, wäre nicht das erste mal.
Wenn du es deaktivierst, warte bitte etwas länger - wenn du immer noch ein Speicherleck hast und das Jabber Modul deaktivierst dauert es etwas länger bis der Fehler wieder auftritt.

Ansonsten noch ein paar Ideen zu deinem Problem:

Mach als erstes mal das, was rudolfkoenig die empfiehlt. Starte fhem in einer screen session und checke ob du da mehr Infos erhälst.

Überprüf mal die limits vom laufenden Perl -
cat /proc/<pid von fhem>/limits

Achte speziell auf die max open files, die sollten bei einem Standard konfigurierten System 1024 soft limit betragen.


Ich hatte ein ähnliches Problem mal in meiner Clusterserverumgebung, als das Speicherbackend gesponnen hat.
Dort sind auf einmal alle Linuxsysteme gestanden, aber komplett.
Das hatte damit zu tun, dass Linux nicht mehr schnell genug sein Journal auf die Festplatte gebracht hat und nach einer weile haben sich die Systeme aufgehangen.
Daraus folgt: Check mal deine SD Karte im Pi und wechsle sie ggfs. aus.


Ansonsten könnte ich mir nur noch vorstellen, dass die Netzwerkverbindung vom Pi Zero ein Problem hat, das würde auch die ganzen CLOSE_WAIT erklären.
Was für Geschwindigkeiten hast du zum Raspi Pi zero (der ja nur über WLAN angebunden ist)?
Du kannst das z.b. mit FileZilla testen indem du mal ein paar files drauf und wieder runterziehst.

Ist die Verbindung stabil oder bricht die Transferrate runter oder sogar ganz ab?

Ich hatte an einem Pi3 mal das Problem, dass ich einen Hardwarebug am WLAN Modul hatte und er die ganze Zeit die Connection aufgebaut und wieder geschlossen hat.
Den hab ich nun über LAN angeschlossen und alles läuft geschmeidig.


So, ich hoffe ich konnte dir ein paar Ansätze zum nachforschen geben :)

Grüße,
BioS
FHEM auf Debian in ESXi5 VM
Homematic mit HMLAN
Raspi mit Pilight für Relais der Heizung

borsti67

Moin BioS,

Zitat von: BioS am 07 Januar 2018, 11:06:05
Wenn ich Nachrichten per Jabber verschicke, bekomme ich keine CLOSE_WAIT Meldungen.
Der Witz ist, dass ich die Meldungen im lsof sehe, auch wenn GAR KEINE Nachrichten verschickt wurden... Offenbar genügt das Aufrechterhalten der Verbindung, um das Problem zu verursachen.
So sehe ich z.B. im Jabber-Client, dass heute Nacht um 0:29 ein FHEM-Neustart ausgelöst wurde (das ist eine der wenigen Nachrichten, die ich auf diesem Wege versende ;)), danach 0:34:46 abgemeldet, 0:34:49 angemeldet, das gleiche 0:40:21 - 0:40:24. Das war's bis jetzt eben, und lsof zeigt mir aktuell 127 CLOSE_WAIT zu meinem Jabber-Server. :(

ZitatIch würde sagen die "too many open files" Meldung, wie auch dein Absturz von FHEM ist alles Auswirkung und nicht die Ursache.
Ist eigentlich auch mein Verdacht, aber ich habe keine Idee, wo ich suchen soll, denn alle Belastungs-Tests, die ich vor der aktiven Nutzung gemacht habe, zeigten keine Probleme...

ZitatProbier sicherheitshalber trotzdem mal mein Modul zu deaktivieren, wer weis was mit neueren XMPP Perl Modulen wieder alles kaputt gegangen ist, wäre nicht das erste mal.
Wenn du es deaktivierst, warte bitte etwas länger - wenn du immer noch ein Speicherleck hast und das Jabber Modul deaktivierst dauert es etwas länger bis der Fehler wieder auftritt.
Ja, das ist momentan mein einziger Anhaltspunkt. Wenn trotzdem nach 2 Tagen ein Neustart erfolgt war's DAS schon mal nicht.  ::)

ZitatMach als erstes mal das, was rudolfkoenig die empfiehlt. Starte fhem in einer screen session und checke ob du da mehr Infos erhälst.
Das ist etwas unpraktisch, da der Pi Zero W ausschließlich per WLAN angebunden ist, es gibt keinen LAN oder Debug-Port (letzteres Vermutung meinerseits, habe nicht gesucht)...
Man müsste doch die Ausgaben auch so in eine Datei umleiten können - ich muss da noch mal nachschlagen, bin da schon zu lange raus.

ZitatÜberprüf mal die limits vom laufenden Perl -
Nichts ungewöhnliches, würde ich meinen:
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             3405                 3405                 processes
Max open files            1024                 4096                 files
Max locked memory         65536                65536                bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       3405                 3405                 signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

ZitatDas hatte damit zu tun, dass Linux nicht mehr schnell genug sein Journal auf die Festplatte gebracht hat und nach einer weile haben sich die Systeme aufgehangen.
Daraus folgt: Check mal deine SD Karte im Pi und wechsle sie ggfs. aus.
Das Problem hatte ich mit ersten Karte, die war definitiv hin: Nach ca. 2 Wochen Dauerbetrieb fiel FHEM aus mit unbekannten Prozeduren etc, und tatsächlich waren in den fraglichen .pl-Dateien reihenweise Sonderzeichen (in der Zeit ist KEIN Update erfolgt). :( Seitdem habe ich eine SanDisk Class10, die war im Schreibtest sehr performant.  :-\

ZitatAnsonsten könnte ich mir nur noch vorstellen, dass die Netzwerkverbindung vom Pi Zero ein Problem hat, das würde auch die ganzen CLOSE_WAIT erklären.
Was für Geschwindigkeiten hast du zum Raspi Pi zero (der ja nur über WLAN angebunden ist)?
Ist nicht soo doll, 1,8 - 2,5 MB/s (wobei die Rate pro Datei stabil ist). Die FritzBox 7390 würde auch 130 MBit schaffen, aber derzeit ist der Pi "nur" mit 65/65 verbunden (da sollte also auch mehr drin sein, aber wer weiß, was der On-Board-Chip bzw dessen Antenne schafft...).

ZitatSo, ich hoffe ich konnte dir ein paar Ansätze zum nachforschen geben :)
Auf jeden Fall! Herzlichen Dank!
cu/2
Borsti
---
FHEM 5.8 auf Synology DS211j (bis 11/17) | FHEM 6.0 auf Raspi Zero W (bis 11/20) | FHEM 6.2 als VM in Synology DS1815+ (ab 11/20)