Autor Thema: Warum beendet sich FHEM immer mal wieder ? - Jemand anders auch betroffen ?  (Gelesen 2218 mal)

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
Hallo Gemeinde,

ich nutze FHEM nun schon seit über 2 Jahren mit diversen HomeMatic - Komponenten.
Anfangs hatte ich 2 Raspberry's am laufen. Einer für die Wohnung, der andere für unsere Energiesparte.
Seit ca. 3 Monaten habe ich das System umgestellt. Es läuft jetzt auf einem Lüfterlosen Mini-PC mit Windows 7 als Host-System mit nun 2 virtuellen Maschinen und FHEM drauf. Das VM-System ist VMWare Workstation Pro. Als Server nutze ich Ubuntu 16.04 LTS.

Das ganze läuft verdammt gut und schnittig.

Doch bei beiden Systemen, sprich, den Raspi's und jetzt auch bei den VM's, tauchte es immer nach einer Zeit auf, dass sich FHEM einfach beendet. Ohne irgendwelche Einträge im log oder sonst irgendwas. Ich dachte erst, dass es etwas mit dem Speicher zu tun hatte. Doch das ist nicht wirklich nachweislich.

Dann hatte ich das Update unserer FritzBox in Verdacht. Bin da eine Version zurück gegangen. Ohne Erfolg.

Auch hatte ich erst den Verdacht, dass etwas mit dem WLAN meines Handy's zu tun haben könnte, da ich Abstürze beobachten konnte, wenn ich mit dem Handy unser Netzwerk betreten oder verlassen habe. Doch nach dem Umstieg auf die VM's und Update auf Version 5.8 war es erst komplett weg. Obwohl ich mit dem Handy wieder ganz normal per WLAN unterwegs war. Also schied das auch aus.

Auch gibt es keine Zeitfenster, wo es sich weghängt. Es kann mal 2 mal pro Tag sein, dann aber kann es sein, das es 2 Tage so läuft, ohne sich zu beenden.

Habt ihr das auch bei euren Systemen ?

Woran könnte es liegen ?

Viele Grüße

André

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3570
    • Meine Seite im fhemwiki
Also ich denke die meisten werden ein solches problem nicht haben, das würdest Du sonst hier lesen.

Wenn es wirklich keinerlei Log-einträge gibt, ist es auf vermutlich nicht ganz einfach das einzukreisen.

Wenn es auf verschiedenen Plattformen passiert ist es vermutlich kein Problem des darunterliegenden Systems.

Zum Eingrenzen, würde ich erstmal  empfehlen loglevel global auf 4 (oder wenn nötig sogar auf 5) zu setzen.
Ausserdem könntest Du einzelne Devicetypen deaktivieren (also alle HM-devices / alle notifies etc)


Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 8179
    • Otto's Technik Blog
Hallo André,
Habt ihr das auch bei euren Systemen ?
absolut nicht!
Bei mir laufen derzeit 6 Systeme, die beende alle ich, sonst laufen die ewig durch.  ;)
Ist der Service wirklich beendet? Oder ist FHEM nur nicht erreichbar?

Gruß Otto
Viele Grüße aus Leipzig
RaspberryPi,HMLAN,HMUART,Homematic,Fritz!Box 7490,Sonos,ET9200,Arduino nano,ESP8266

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
Hi viegener !

das ist ja das komische.
Es ist nix verändert worden, während der Umstellung von Raspi auf VM.

Ich hatte hier mal einen Beitrag gefunden, wo jemand auch so ein Problem hatte.
Da wurde es dann mit einem Skript im Crontab gelöst, welches bei einem beenden des FHEM Servers diesen neu startet.
Ich muss da nochmal genau gucken. Ich hatte das nämlich auch umgestezt. Muss aber wohl im Crontab -e nochmals den User ändern.

Komisch ist auch, dass meist erst der Energieserver anfängt, sporadisch auszusetzen, ein paar Tage später folgt meist der Server für die Wohnung.

Alles seltsam...

Wenn ich unter /etc/init.d/fhem status aufrufe, kommt immer fhem is not running.
Es lässt sich dann sofort wieder mit dem start - Befehl starten und läuft.

VG

André

Offline DeeSPe

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3639
  • Wer anderen eine Bratwurst brät...
Mittlerweile habe ich mehrere Hostsysteme durch.
Von Raspbian, über Debian auf Brix/VIVO und auch Debian in VM auf Virtual Box.
Solange nicht irgendein Modul, meist mein eigenes wg. Testsystem, FHEM herunterreißt laufen alle meine Systeme bisher sehr stabil. Das sich der FHEM Dienst einfach so verabschiedet habe ich noch nie erlebt.

Ich weiß, für Dich sind das keine guten News, aber wie viegener schon meint, man kann es leider nur Stück für Stück durch Abschalten potentieller Kandidaten versuchen zu klären.

Gruß
Dan
FHEM 5.8, Brix, VIVO mini, RPi3, Debian Jessie, ZME_UZB1
HM-CFG-LAN, HM-MOD-UART-WIFI, HUE, HarmonyHub, JeeLink, CO20
Hyperion auf RPi Zero W, Sonos, viel Z-Wave und HM
alles per HomeKit steuerbar
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 8179
    • Otto's Technik Blog
Da wurde es dann mit einem Skript im Crontab gelöst, welches bei einem beenden des FHEM Servers diesen neu startet.
Ich muss da nochmal genau gucken. Ich hatte das nämlich auch umgestezt. Muss aber wohl im Crontab -e nochmals den User ändern.
Sorry aber das ist mit Sicherheit der falsche Weg.

Da es ja mit Deiner FHEM Instanz mitwandert und beide Instanzen betroffen sind, muss es defacto an dem liegen was Du innerhalb von FHEM tust. Was ist bei beiden Instanzen gleich?

Gruß Otto
Viele Grüße aus Leipzig
RaspberryPi,HMLAN,HMUART,Homematic,Fritz!Box 7490,Sonos,ET9200,Arduino nano,ESP8266

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17961
Wenn FHEM ohne Warnung sich beendet, dann steht meist irgendetwas in der Console. In solchen Problemfaellen lohnt sich FHEM in screen mit  "attr global logfile -" zu starten, dann kann man sich spaeter zu diesem screen "attachen", und die letzte Meldung anschauen.

Btw. mein FHEM laeuft auch durch, ich kann mich in den letzten zehn Jahren an keinen unbeabsichtigten Stop mich erinnern (bis auf einem Motherbord-Defekt und ein Stromausfall).  Auf der anderen Seite bin ich aber sehr konservativ, was den Einsatz von FHEM-Modulen betrifft.

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 8179
    • Otto's Technik Blog
mach doch einfach mal bei beiden ein fheminfo und poste das Ergebnis, dann können wir schauen ob es ein Modul gibt was wir nicht im Einsatz haben.

Gruß Otto
Viele Grüße aus Leipzig
RaspberryPi,HMLAN,HMUART,Homematic,Fritz!Box 7490,Sonos,ET9200,Arduino nano,ESP8266

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
Okay,

hier mal das fheminfo zum Wohnungssystem:
Fhem info:
  Release  : 5.8 FeatureLevel: 5.8
  OS       : linux
  Arch     : i686-linux-gnu-thread-multi-64int
  Perl     : v5.22.1
  uniqueID : fcc36d02ec312b262d849e35ff1de8f3
  upTime   : 11:22:18

Defined modules:
  CALVIEW       : 1
  CUL_HM        : 70
  Calendar      : 1
  DOIF          : 6
  Dashboard     : 1
  FHEM2FHEM     : 1
  FHEMWEB       : 3
  FRITZBOX      : 1
  FileLog       : 10
  HMUARTLGW     : 1
  HTTPMOD       : 6
  PHTV          : 1
  SMAEM         : 1
  SMAInverter   : 1
  SVG           : 11
  TelegramBot   : 1
  VantagePro2   : 1
  alexa         : 1
  allowed       : 2
  at            : 3
  autocreate    : 1
  dummy         : 17
  eventTypes    : 1
  notify        : 50
  readingsGroup : 6
  telnet        : 1
  weblink       : 1

Defined models per module:
  CUL_HM        : ActionDetector,HM-CC-RT-DN,HM-ES-PMSw1-Pl,HM-LC-SW4-WM,HM-OU-CFM-PL,HM-PBI-4-FM,HM-SEC-MDIR-2,HM-SEC-SC-2,HM-SEC-SCo

Transmitting this information during an update: no
You can change this via the global attribute sendStatistics



Und hier zum Energiesystem:

Fhem info:
  Release  : 5.8 FeatureLevel: 5.8
  OS       : linux
  Arch     : i686-linux-gnu-thread-multi-64int
  Perl     : v5.22.1
  uniqueID : 1cbfc54b8db529de9af5ecab92963a1f
  upTime   : 02:23:31

Defined modules:
  DOIF                  : 3
  Dashboard             : 1
  ElectricityCalculator : 4
  FHEMWEB               : 3
  FileLog               : 6
  HTTPMOD               : 1
  SMAEM                 : 1
  SMAInverter           : 1
  SVG                   : 6
  VantagePro2           : 1
  Weather               : 1
  autocreate            : 1
  dummy                 : 6
  eventTypes            : 1
  notify                : 11
  readingsGroup         : 6
  telnet                : 1
  weblink               : 2

Transmitting this information during an update: no
You can change this via the global attribute sendStatistics

Das mit der Crontab - Geschichte finde ich auch keine Lösung. Ich möchte halt wissen, wo es weg kommt.
Da einfach mal Stück für Stück Ursachenforschung betreiben...

Viele Grüße und besten Dank

André



Offline schka17

  • Sr. Member
  • ****
  • Beiträge: 819
Ich kann nur sagen dass ich auch manchmal diese Problem habe bzw. hatte. Vor einiger Zeit war es definitiv ein Speicherproblem, also nicht HW sondern dass der perl Prozess immer mehr Speicher genutzt und nicht mehr freigegeben hat (cubieboard2 mir armbian). Nach einem Wechsel auf eine amd platform mit debian und 2GB Ram fuel dieses Problem weg. Jetzt passierts noch ab und zu dass im Logfile die Meldung "too many files open....." aber da läuft der prozess noch, fhemweb antwortet aber nicht mehr. Tja, und noch seltener wird Fhem ohne irgendeine Meldung im Logfile beendet. Workaround für mich ist das ich systemd verwende und fhem einfach wieder gestartet wird. Ich habe viel Zeit mit debugging verbracht und mittlerweile ist es mir zu aufwändig, also lebe ich jetzt mal mit dieser Situation.

Zur weiteren Information, das betrifft nur eine von mehreren Fhem Instanzen, leider die zentrale. Ich habe noch zwei sub-FHEM's  einedavon läuft bis auf die Updates die ich durchführe ohne Probleme auf einem Raspberry B (mit der ersten SD Karte) ohne Probleme


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

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 8179
    • Otto's Technik Blog
Hi André,

also mein Ergebnis -> eventuell eines von diesen Modulen:
  Dashboard             : 1
  SMAEM                 : 1
  SMAInverter           : 1
  VantagePro2           : 1
Die hast Du in beiden Instanzen und ich habe die nicht. Vielleicht brauchst Du die nicht zwingend in beiden Instanzen und nimmst sie in einer mal raus.

Mag ein schräger Ansatz sein, aber Versuch macht kluch  8)
Gruß Otto
Viele Grüße aus Leipzig
RaspberryPi,HMLAN,HMUART,Homematic,Fritz!Box 7490,Sonos,ET9200,Arduino nano,ESP8266

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
Hallo Otto,

ich warte jetzt nochmal einen "Crash" ab. Was komisch ist, ist die Tatsache, dass die Wetterstation (Vantage Pro 2) sich dann auch mit weg hängt. Diese sendet ja an Davis die Daten, um sie später per App abrufen zu können. Muss mal gucken, ob ich das deaktivieren kann. War damals noch von vor der Einbindung in FHEM. Die Station kommt dann, nachdem so ein Crash auftrat, auch nicht wieder ins Netz. Auch per App steht dann alles (man sieht den Zeitstempel des letzten gesendeten Wertes). Hatte die Station jedoch seit gestern nach dem letzten Crash noch nicht wieder resettet, damit sie erstmal nicht im Netz war/ist.

Ich habe den VM's jeweils 1GB RAM mit 40GB HDD Platz und einen Prozessorkern spendiert. ich könnte beide noch auf 2 GB RAM hieven. Das sollte vom Hostsystem gut machbar sein.

VG

André

PS.: Als der letzte Beitrag geschrieben wurde, habe ich die Davis wieder ans Netz gelassen.
       Mal abwarten...

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
Ich habe gestern Abend nach dem letzten Post hier nochmal über Geschichte mit dem VantagePro Modul nachgedacht.
Das spontane beenden von FHEM gab es vorher auch schon. Da war die Station und das Modul noch nicht in Betrieb. Aber warum diese als einziger Client dann aus dem Intranet fliegt und erst wieder kommt, wenn ich kurz den Strom von der Wetterstation nehme, bleibt mir ein Rätsel.

VG

André

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 3728
Ist fhem wirklich "weg" oder sagt dieses "nur" das Init-System?
ps aux | grep [f]hem
Auch interessant, währe zu der Ausfallzeit das kernlog. z.B. könnte es auch der oem-Killer sein ..
tail /var/log/kern.log
- Bitte um Input für Output
- When there is a Shell, there is a Way

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

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
Danke für die Antworten !

So. Der Energieserver hatte sich heute Vormittag wieder weg gehangen. Die App der Wetterstation zeigt auch, dass sich die Station um 6Uhr heute Morgen auch wieder ausgeklingt hat und keine Daten mehr sendet. Ich habe den Energieserver nun neu übers Init gestartet. Leider bevor ich die Antwort von Wernieman gelesen hatte. Ich habe jetzt dort auf dem Server die IP der Station geändert. Reicht das wohl für einen Test, oder muss ich das ganze Modul rausnehmen ? Also diese Geschichte mit dem Ethernetanschluss der Davis Wetterstation ist von Davis mehr wie rudimentär.

VG

André

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
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.. ?

« Letzte Änderung: 23 Mai 2017, 11:22:30 von Stargazer »

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2027
Stacktrace aktivieren!
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktoren/Sensoren/Winmatic/Keymatic/Thermostate, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony
https://paypal.me/mm0

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
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 ?
« Letzte Änderung: 23 Mai 2017, 20:00:58 von Stargazer »

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2027
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 Aktoren/Sensoren/Winmatic/Keymatic/Thermostate, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony
https://paypal.me/mm0

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17961
@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
Zitat
FHEM 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.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4593
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

 
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline schka17

  • Sr. Member
  • ****
  • Beiträge: 819
@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

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287
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 ?



Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 3728
Zitat
Doch 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

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

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 287

Zitat
z.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é

Offline borsti67

  • Full Member
  • ***
  • Beiträge: 410
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 5.8 auf Raspi Zero W (ab 11/17)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17961
Zitat
Auffä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.

Zitat
Der 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.

Offline borsti67

  • Full Member
  • ***
  • Beiträge: 410
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 5.8 auf Raspi Zero W (ab 11/17)

Offline BioS

  • Developer
  • Full Member
  • ****
  • Beiträge: 104
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

Offline borsti67

  • Full Member
  • ***
  • Beiträge: 410
Moin BioS,

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. :(

Zitat
Ich 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...

Zitat
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.
Ja, das ist momentan mein einziger Anhaltspunkt. Wenn trotzdem nach 2 Tagen ein Neustart erfolgt war's DAS schon mal nicht.  ::)

Zitat
Mach 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
Zitat
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.
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.  :-\

Zitat
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)?
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...).

Zitat
So, 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 5.8 auf Raspi Zero W (ab 11/17)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17961
Mit screen meinte ich:
% ssh rpi_zero
% screen
% service fhem stop (oder vergleichbares)
% cd /opt/fhem
% perl fhem.pl -d fhem.cfg
% Ctrl-a Ctrl-d (damit meine ich Ctrl halten, erst a, dann d)
% exit
Wenn FHEM abgestuerzt ist, dann screen reattachen mit:
% ssh rpi_zero
% screen -r
(nicht getestet, mitdenken erwuenscht).