fhem.pl 99% CPU

[schka17]

Hallo,

habe leider seit ca. zwei Wochen das Problem dass fhem.pl auf 99% CPU Auslastung geht und dann natürlich nichts mehr geht. ich kann ohne Probleme alle anderen services erreichen, also auch über Putty einloggen und auf shell ebene arbeiten, aber fhem ist tot.

Entsprechend geht dann fhem stop auch nicht mehr. einzig das killen des prozesse hilft, aber damit habe ich mir jetzt schon zweimal die ganze config zerschossen und das ist kein dauerzustand.

Last but not least, wenn das Ding einmal nicht funktioniert wenn ich nicht zuhause bin dann ist der WAF gleich null, da muss jetzt also eine Lösung her, hat jemand eine Idee:

hier mal ein paar Basisdaten:

RaspberryPI (ich habe alle versionen A/B/256MB/512MB ausprobiert, mit allen das gleiche Problem).
Ich habe verschiedene SD-Cards verwendet, aktuell eine Samsung 16GB Class 6 HC, auch alle anderen waren Class6

Linux HAL9000-3 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux

2013.04.07 17:02:58 1: Including fhem.cfg
2013.04.07 17:02:59 3: telnetPort: port 7072 opened
2013.04.07 17:02:59 3: WEB: port 8083 opened
2013.04.07 17:02:59 3: WEBphone: port 8084 opened
2013.04.07 17:02:59 3: WEBtablet: port 8085 opened
2013.04.07 17:03:00 3: Opening HMLAN device 192.168.255.35:1000
2013.04.07 17:03:00 3: HMLAN device opened
2013.04.07 17:03:00 1: Including ./FHEM/owconfig.cfg
2013.04.07 17:03:00 3: OWServer: Opening connection to OWServer 192.168.255.9:4304...
2013.04.07 17:03:00 3: OWServer: Successfully connected to 192.168.255.9:4304.
2013.04.07 17:03:01 1: Including ./FHEM/CUL.cfg
2013.04.07 17:03:01 3: Opening CUNO1 device 192.168.255.10:2323
2013.04.07 17:03:01 3: CUNO1 device opened
2013.04.07 17:03:01 3: CUNO1: Possible commands: mBCFiAIGMRTVWXOefltuxEcq
2013.04.07 17:03:02 1: Including ./FHEM/netzwerk.cfg
2013.04.07 17:03:02 1: Including ./FHEM/webcams.cfg
2013.04.07 17:03:02 1: Including ./FHEM/infrarot.cfg
2013.04.07 17:03:02 2: Switched CUL_IR_1 irReceive to ON_NR
2013.04.07 17:03:02 1: Including ./FHEM/heizung.cfg
2013.04.07 17:03:10 1: Including ./FHEM/HMS.cfg
2013.04.07 17:03:11 1: Including ./FHEM/FS20.cfg
2013.04.07 17:03:11 1: Including ./FHEM/Homematic.cfg
2013.04.07 17:03:13 1: Including ./FHEM/Weather.cfg
2013.04.07 17:03:14 1: Including ./FHEM/Dummys.cfg
2013.04.07 17:03:14 1: Including ./FHEM/notify.cfg
2013.04.07 17:03:14 1: Including ./log/fhem.save
2013.04.07 17:03:17 0: Server started with 297 defined entities (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 3008 2013-04-01 11:19:27Z rudolfkoenig $, pid 24736)

Ich habe also HMLAN, CUNO 1.46 (wegen IR) und einen remote OWServer (2.Raspberry) im Einsatz.
Als Aktoren/sensoren ziemlich alles gemischt, KS300, FS20, HM, HMS, OneWire, und an einer 3. FHEM Instanz die auf einer virtuelle Ubuntu Maschine läuft noch eine Zwave Umgebung (ist aber noch nicht integriert).Die beiden anderen Instanzen Raspebrry/ubuntu laufen seit längerem einwandfrei, aber die zentrale Instanz spinnt. ich habe keine besonderen logeinträge mit Ausnahme disconnect/reconnect HMLAN.

Hat jemand eine Idee wo ich zu suchen anfangen kann?

Gruss

Karl


 

[Rohan]

Hallo Karl,

... habe leider seit ca. zwei Wochen das Problem dass fhem.pl auf 99% CPU Auslastung geht und dann natürlich nichts mehr geht. ich kann ohne Probleme alle anderen services erreichen, also auch über Putty einloggen und auf shell ebene arbeiten, aber fhem ist tot.

jetzt hier weiter, da ich es in dem anderen Thread selbst vorgeschlagen hatte:

Deine Konfiguration als Ganze ist ja nicht gerade von "schlechten Eltern" ;) wobei ich relativ viele Elemente selbst gar nicht benutze.

Hier wirst du evtl. nur nach dem Ausschlussverfahren arbeiten können, also erst mal nur ein Grundsystem fahren und dann nach und nach die einzelnen "includes" einbinden. Irgendwann wird sich "der Bösewicht" zeigen, der da die Systemlast erzeugt. Ob das bei einem laufenden Produktivsystem geht, kannst nur du selbst beantworten.

Das als mein erster Ansatz.

Gruß
Thomas

[schka17]

Hallo thomas,

Ja das ist genau das Problem vor allem weil es erst nach ungefähr 30 stunden auftritt.

Ich habs aber vorher auch schon mal genauso wie vorgeschlagen gemacht und das problem zumindest mal auf drei problembereiche eingegrenzt nämlich der remote owserver, HMLAN, oder CUNO.

Die anderen komponentent haben keinen einfluss.
Immer wenn ich einen dieser drei disable läufts, zumindest länger als 30 stunden. Ich hatte zuerst ein netzwerktiming problem im verdacht da ich den remote owserver über ein relativ dürftige wanverbindung connected habe, aber das wars doch nicht. Die anderen komponenten, also HMLAN, CUNO und raspberry hängen an einem 1GB switch, da solltest es keine netzwerkprobleme geben.
Der nächste verdacht waren die schreibvorgänge da ich doch relative viele logfiles schreibe und das uu probleme mit der sd card haben könnte.
Also habe ich auch die logfiles grösstenteils disabled und auch die sd card getauscht, auch erfolglos.
Ich bin ja leider kein hacker, aber cool wäre es wenn man herausfinden könnte an welcher stelle im code dieser loop passiert, falls es wirklich loopt, schaut aber so aus. Ich habe mir zumindest die openfiles angesehen und zum zeitpunkt des loopens sind auf jeden fall alle logfiles vom fhem.pl geöffnet, ich habe aber noch nicht kontrolliert ob das auch im normalzustand so ist.
Das nächste was ich überlegt hatte war das ich das ganze mal auf einer virtuellen ubuntu maschine auf meinem vmware server laufen lasse, aber den will ich eigentlich abdrehen, also auch wenn es dann dort geht weiss ich dann nicht mehr.

Und das blödeste ist halt dass ich beruflich sehr viel unterwegs bin, und wenn das fhem hängt wenn ich nicht zuhause bin, dann kann meine frau nicht mal fernsehen weil das alles über eine harmony und dem cuno gesteuert wird, das geht gar nicht.

Also für jede weitere idee bin ich dankbar

Gruss karl

[Puschel74]

Hallo,

CUNO und raspberry hängen an einem 1GB switch

Ich bin mir zwar nichtmehr sicher aber war da nicht irgendwas mit CUNO an GBit-Lan?

Ich hab meine an 100MBit-Switch laufen.
Wenn du irgendwo noch einen rumliegen hast versuch mal den CUNO am "langsameren" Switch.

Grüße

[Rohan]

... Ich bin mir zwar nichtmehr sicher aber war da nicht irgendwas mit CUNO an GBit-Lan? ...

Ja, zwar lt. Wiki (ganz unten) "nur" mit DHCP, aber wer weiß.

Ich würde in solch einer Situation auch nach jedem Strohalm greifen. Am Besten wäre (zu Testzwecken) z.B. auch ein "managed Switch", bei dem evtl. Netzwerk-Fehler eher entdeckt werden können. Ich weiß z.B. aus eigener Erfahrung, dass gerade im GBit-Bereich Switch und Netzwerk-Karte gerne Probleme machen, wenn beide oder auch nur einer auf "auto-sensing" stehen (Switche aus dem Business-Bereich). Hier hilft dann nur eine feste Speed-Rate auf beiden Seiten.

Gruß
Thomas

[Rohan]

Ich setze mal einen neuen Post, damit der Hinweis nicht untergeht:

Wofür manche Consumer-Switche Ursache sind, kann man z.B. hier nachlesen.

Muss / Wird jetzt nicht auf den konkreten Fall zutreffen, aber ...

Gruß
Thomas

[schka17]

Hallo,

ich habe da einige linux commandos gefunden die doch helfen das Problem ein bischen einzugrenzen, und zwar in meinem Fall lsof und strace.

Ich habe am freitag nachmittag den restart disabled und wie erwartet ist heute fhem wieder "gefreezed". dann hat sich folgendes Fehlerbild gezeigt:
statt üblicherweise einem fhem.pl prozesse waren zwei aktiv, wobei der zweite vom ersten fhem prozess gestartet wurde und dann die hohe CPU Last verursacht.

mit strace habe ich dann herausgefunden das process a mit einem read auf pipe zum process b gewartet hat, und entsprechend auch keine cpu last erzeugt hat.

process b hat gelooped und zwar mit den beiden syscalls select auf FD9 und recvfrom FD9

netstat hat gezeigt dass das ein netzwerk socket ist, allerdings mit einem link auf eine nicht /mehr) vorhandene node und nicht indentifizierbaren protocol. googlen nach dieser meldung hat mich irgendwie zu der vermutung gebracht dass das FD limit überschritten wurde, soll z.b. vorkommen wenn ein socket nicht sauber geschlossen wird.

weiters hat mir netstat gezeigt dass die verbindungen zum owserver und zum cuno normal aussehen, nur die verbindung zum HMLAN ist nicht sichtbar, das war dann am gerät selbst auch klar sichtbar dass keine verbindung besteht. tcpdump hat auch gezeigt dass keinerlei datenverkehr zum oder vom HMLAN existiert. resetten des HMLAN hat nichts gebracht.

Also mein verdacht ist nun dass das Problem im Bereich des Homematic modules bzw. in der Verbindung zum HMLAN. Dort habe ich auch immer wieder disconnects, und die letzten zwei meldungen im fhemlog waren diese:
2013.04.20 11:59:44 1: 192.168.255.35:1000 disconnected, waiting to reappear
2013.04.20 11:59:49 1: 192.168.255.35:1000 reappeared (HMLAN)

Danach stand fhem.

killen der beiden fhem prozesse und starten von fhem und jetzt läufts wieder, es ist jetzt auch wieder nur ein prozess da und netstat zeigt alle netzwerkverbung an.
tja, hat wer eine idee was nun?

gruss
Karl

[Rohan]

Hallo Karl,

also HMLAN-Disconnects habe ich mehrere am Tag und ich habe mittlerweile hier von einigen gelesen, die ähnliches haben. Ist für mich aber eher kosmetisch, führt auf jeden Fall nicht zum Freeze von irgendwas.

Was evtl. problematisch ist, sind die 2 Fhem-Prozesse (hast du blocking.pm oder presence in Gebrauch?). HMLAN erlaubt nur eine Netzwerkverbindung. Falls der 2. Fhem-Prozess als 2. Netzwerkverbindung von HMLAN erkannt wird, ist er afaik nicht mehr ansprechbar.

Wann war dein letztes Update von Fhem?

Gruß
Thomas

[schka17]

Hallo Thomas,

das habe ich im Forum auch gelesen deswegen habe ich das bisher ignoriert.
Ich habes keines der genannten Module im Einsatz und zum Zeitpunkt wo fhem nicht mehr reagiert gibt es keine verbindung zum HMLAN. Ich kann mir auch nicht erklären wie der zweite prozess gestartet wird, jedenfalls definitiv vom ersten fhem Prozess.
Den letzten update habe ich am 13.4.2013 um 11:08 gemacht.
hier diee module die ich im einsatz habe.
Defined modules:
  CUL        : 1
  CUL_EM     : 1
  CUL_HM     : 46
  CUL_IR     : 1
  CUL_WS     : 9
  FHEMWEB    : 5
  FHT        : 3
  FLOORPLAN  : 6
  FS20       : 31
  FileLog    : 63
  HMLAN      : 1
  HMS        : 8
  IPCAM      : 1
  KS300      : 1
  OWDevice   : 9
  OWServer   : 1
  Twilight   : 1
  at         : 9
  autocreate : 1
  dummy      : 24
  notify     : 16
  telnet     : 1
  weblink    : 25

Defined models per module:
  CUL        : CUN
  CUL_HM     : HM-LC-SW1-FM,HM-LC-SW1-PL2,HM-LC-SW2-FM,HM-LC-SW4-WM,HM-PB-4DIS-WM,HM-PBI-4-FM,HM-SEC-SC,HM-SEC-TIS,virtual_2
  FHT        : fht80b
  FS20       : fs20sm8,fs20st,fs20st2
  OWDevice   : DS1420,DS18B20,DS18S20,DS2408

gruss
Karl

[Rohan]

Hallo Karl,

anfangs im Thread hattest du neben HMLAN auch CUNO bzw. OWServer als mögliche bzw. eventuelle Verdächtige genannt. Ich selbst fange mit 1-Wire erst noch an und habe da noch nicht so die Ahnung, also sorry für die folgende Frage(n): Welche (ich frage bewusst nicht "wessen" ;) ) Module nutzt du? Schon mal an eine(n) Umstellung/Wechsel <=> gedacht?

Edith ergänzt dann noch: Da offene / defekte Netzwerkverbindungen eine Rolle spielen, wirst du evtl. um einen Einsatz eines Netzwerk-Sniffers nicht umhin kommen. Hat zwar eine flache Lernkurve, aber ...

Gruß
Thomas

[schka17]

Hallo Thomas,

ich weiss nicht wessen Module das sind, soviel ich gesehen habe gibt es die, die nur großbuchstaben haben und die mit groß und kleinbuchstaben, diese verwende ich also OWServer und OWDevice. das funktioniert perfekt, also denke ich nicht daran zu wechseln, aber ich kann mich noch erinnern dass dafür einen Grund gab, aber ich weiss nicht mehr welchen, möglicherweise war damals eines der devices nicht unterstützt????

zum thema Netzwerk, ich denke es ist kein Netzwerkproblem das glaube ich ja mit tcpdump schon herausgefunden, das problem ist eher beim ansprechen des sockets weil es den filehandler zu diesem zeitpunkt nicht mehr gibt. lt. tcpdump gibts keinerlei daten, also auch keine fehler, zum zeitpunkt des Fehlers.

so sieht es aus wenn es funktioniert, im falle des fehler gibts diesen socket bzw.FD nicht mehr, also kanns gar keine netzwerkverbindung geben.
perl      27482             fhem   10u     IPv4    2350618      0t0        TCP 192.168.255.13:39912->192.168.255.35:1000 (ESTABLISHED)

gruss
Karl

[Rohan]

Hallo Karl,

sorry, aber an der Stelle bin ich dann raus, denn hier ist eine Fernwartung bei nicht ähnlicher Umgebung für mich nicht möglich.

Was ich dir aus eigener Erfahrung nur noch sagen kann ist, dass mein Fhem (hier ohne blocking.pm) starken Schluckauf bekommt, wenn meine Arduinos (per Ethernet angebunden) nicht reagieren. Da ich deren 1-Wire-Sensoren aber sowieso auf RPi(s) mit diesen Modulen umstellen werde, verwende ich dafür keinen Gehirnschmalz mehr.

Ich lese aber weiter mit.

Gruß
Thomas

[Prof. Dr. Peter Henning]

Auch wenn Rohan netterweise empfohlen hat, zu den von mir geschriebenen 1-Wire-Modulen zu wechseln: Das halte ich vorerst für nicht nötig.

Auch ist es wenig zielführend, wilde Vermutungen Dritter über Netzwerkfehler mit Sniffern und TCP-Dumps anzugehen: Das Problem liegt offenbar viel einfacher. FHEM stellt hier einen Kindprozess auf die Beine ("fork") und wartet offenbar verzweifelt auf dessen Rückgabewerte.

Das forken passiert in den folgenden Modulen:

FHEMWEB.pm => Zur Ausgabe von Plots
OWServer.pm
PRESENCE.pm

Also erster Schritt: Alle OWServer (und damit alle 1-wire-sensoren) erst einmal auskommentieren. Schauen, ob das Problem weiter besteht, wenn man eine Seite ohne plots aufruft.
Zweiter Schritt: Gleiches mit eventuellen PRESENCE-Definitionen.

Würde mich mal interessieren, was dabei herauskommt.

LG

pah

[schka17]

Hallo pah,

Also ist schon mal eine aussage,

Presence kann ich ausschliessen, verwende ich nicht. Das das ein geforkter prozess kann ich definitv bestätigen, der aufrufende Prozess steht mit einem read auf die pipe zum aufgreufenen prozess. Dieser looped definitv beim zugriff auf einen netzwerk socket. Da mein system automatisieren soll habe ich kaum zugriffe auf fhemweb, somit wäre jetzt der OWServer wieder im Fokus. Wie schon erwähnt greife ich da ja auf eine remoten raspberry im Keller über eine sehr schlchte wlan verbindung zu. Beim letzten auftreten des fehlers habe ich mich zu sehr auf HMLAN konzentriert da dies die neuesten Komponenten waren die ich integriert hatte.
Das blöde an der Geschichte, abgesehen davon dass es nur ca. Alle 30 Stunden passiert, ist dass ich dann alle HM threestatesensoren neu dingsen muss, eigentlich weiss nicht genau was ich da machen aber ich muss jeden Sensor einmal kurz die Anlerntaste drücken, dann gibts scheinbar heftigen funkverkehr (grüne led) und dann sprechen sie wieder mit fhem. Wenn ich das nicht mache kriege ich zwar statusmeldungen aber ich kriege kein readings und kann keine config auslesen, und bekomme nach 24 stunden ohne betätigung eine dead meldung und damit von jedem sensor eine email. Das ist ziemlich lästig.
Ich bin jetzt dann "leider" mal eine Woche im urlaub, davor möchte ich jetzt keine experimente mehr machen, aber danach gehts wieder weiter mit der Fehlersuche, ich werde berichten.

Gruss

Karl

[Rohan]

Tja Prof,

geschnitten ... ich bin nicht nett, zumindest nicht zu jedem ;) (warum nur? ;) )

Wie man aus

Schon mal an eine(n) Umstellung/Wechsel <=> gedacht?

herauslesen kann, dass

Auch wenn Rohan netterweise empfohlen hat, zu den von mir geschriebenen 1-Wire-Modulen zu wechseln

Ich soll eine "Empfehlung" für *deine* Module ausgesprochen haben? Nie nich ... Sorry, aber: Brille nicht geputzt, oder? Ach so... bewusst eingesetzte Verkennung... warum nur? ;)

Das bereits genannte Ausschlussverfahren erkennen wir auch nicht bzw. überlesen wir geflissentlich?

Und

wilde Vermutungen Dritter ...

sagt (mir) genug über deine Intention, die du mit diesem, deinem Post verfolgst/beabsichtigst.

Das mit dem nachfolgend erwähnten Fork hatten wir auch schon und mit dem Module ausklammern ebenfalls.

Aber wenn der TO jetzt bereit ist, entsprechenden Hinweisen nach seinem Urlaub nachzugehen, dann hat dein Post wenigstens etwas gutes gehabt ;)

Danke dafür.

Gruß
Thomas

P.S. Du kannst dich also wieder voll und ganz der "Konkurrenz" widmen.
P.P.S. Wie komme ich nur zu der Ansicht, dass du das nicht tun wirst? ;) Aber, wie schriebst du kürzlich jemandem sinngemäß? "Immer schön sachlich bleiben." Oder gilt das nur für andere?
Edith muss noch einen ergänzen: Ich bin auf deine weitere Argumentationsweise ad hominem gespannt.