FHEM crashed aufgrund zweier unterschiedlicher defines ohne log

[farion]

Hi,

seit heute crashed mein FHEM wenn ich eine dieser beiden defines in meiner config habe relativ zügig nach start (1-10s).

Code Auswählen Erweitern

define jabber Jabber ###server### 5222 ###user### ###password### 1 0
attr jabber OnlineStatus available
attr jabber PollTimer 2
attr jabber RecvWhitelist .*
attr jabber ResourceName FHEM
attr jabber room FHEM

Code Auswählen Erweitern


define MeinWetter Weather 664205 600 de
attr MeinWetter room Status


Log ist leider leer. Kann perl das nicht oder liegt das an mir?
Deswegen habe ich leider keine weiteren Informationen.

Nur eine vage Vermutung ... evtl. irgendwas mit SSL-Zertifikaten ... ich habe zumindest eins von StartCom auf meinem Jabber-Server ... da gibts ja grade Klinsch ... aber vermutlich ist es was völlig Anderes.

Gruss farion

[farion]

Ich bin mir mittlerweile ziemlich sicher, dass es SSL ist.

Auch curl und nginx haben Probleme:

Code Auswählen Erweitern

$ curl https://www.fhem.de
Segmentation fault

Im Nginx-log sehe ich Folgendes sobald ich via ssl drauf zugreife:

Code Auswählen Erweitern

2017/01/07 22:51:45 [alert] 8295#0: worker process 8334 exited on signal 11

Jemand eine Idee, warum das urplötzlich heute um 16:00 kaputt geht ohne, dass ich etwas geändert habe?

Gruss farion

[farion]

So, habe ein neues Image aufgespielt ... scheint jetzt wieder alles zu gehen ...

[farion]

Jetzt habe ich doch noch Probleme bekommen und zwar hängt sich FHEM nach ein paar Minuten auf. Sprich das WebFrontend lädt nicht mehr.

Im Log ist nichts zu sehen. CPU und IO sehen auch gut aus.
Also habe ich die Perl-Pid getraced:

Code Auswählen Erweitern

$ strace -p 14541
Process 14541 attached
read(10,


Code Auswählen Erweitern

$ ls -l /proc/14541/fd/10
lrwx------ 1 root root 64 Jan  8 15:05 /proc/14541/fd/10 -> socket:[106636]

Code Auswählen Erweitern

$ lsof -V | grep 1066
perl      14541             fhem   10u     unix 0xa3c1b000      0t0     106636 socket


Und da komme ich nun nicht mehr weiter.

Gruss farion

[rudolfkoenig]

Damit das hier nicht zu einem traurigen Monolog wird :

- die "standard" FHEM-Module verwenden kein unix socket, ich habe sowas nur bei yowsup und HMCCU gefunden. Habe aber nur in "offiziellen" Module gesucht. Evtl. hilft solche Module zu deaktivieren, damit man sicher ist, und danach dem Modulautor das Problem melden.
- man kann noch genauer was sagen, wenn man fhem mit strace startet:
  strace -o /tmp/xy -f -tt -T perl fhem.pl fhem.cfg
- wenn curl bei sowas einfaches ein segfault liefert, dann ist was oberfaul, und die Entscheidung neu zu installieren war richtig. Ich wuerde den Datentraeger zusaetzlich nochmal pruefen.

[farion]

Den Frust von der Seele schreiben tut auch gut .

Ich hatte dblog aktiv. Das habe ich jetzt mal ausgemacht. yowsup und HMCCUU habe ich nicht. Hier mal meine Liste:

Code Auswählen Erweitern

Defined modules:
  CUL_HM        : 170
  DOIF          : 6
  FHEMWEB       : 1
  FLOORPLAN     : 1
  FRITZBOX      : 3
  FileLog       : 1
  HMLAN         : 2
  HMinfo        : 1
  HTTPSRV       : 2
  Jabber        : 1
  KM271         : 1
  LightScene    : 1
  PRESENCE      : 2
  PROPLANTA     : 1
  at            : 6
  autocreate    : 1
  dewpoint      : 2
  dummy         : 8
  eventTypes    : 1
  notify        : 55
  readingsGroup : 2
  readingsProxy : 21
  siri          : 1

Dazu kommen noch ein paar eigene, die habe ich aber schon ausgeschlossen.

Seit ich den dblog aus habe, hängt fhem nicht mehr für immer. Dafür gefühlt 50% der Zeit. Wenn es "weiter geht" sieht man im strace jede Menge llseeks.
Langsam glaube ich auch an die SD-Karte.

Das mit dem erweiterten Trace probiere ich auch nochmal.

Gruss Frieder

[farion]

Also das am Anfang mit den SSL-Crashes war wirklich ein seltsames Problem ... aber das habe ich ja durch eine Neuinstallation lösen können. Aber das andere Problem mit dem Hänger, da dürft ihr jetzt alle mal ne Runde lachen:

Ich hatte die Neuinstallation gleich auf einem neuen Raspi3 gemacht und den alten Raspi2 für mein DoorPi-Projekt auf die Seite gelegt. Aber eben mit gleicher SD-Karte. Heute auch die SD-Karte getauscht, mit dem gleichen Ergebnis. Dann habe ich es mal geistesgegenwärtig nicht mit dem Chrome probiert, sondern mit dem FF. Irgendwie hatte ich schon so ein komisches Gefühl, weil ssh auch manchmal nicht ging. Hab mir da nix gedacht und ne geistige Notiz gemacht, dass ich mal schauen müsste was meine fancy zsh-config da treibt, die ich vorurteilsbehaftet dafür verantwortlich gemacht habe. JA NIX! Komisch war dann, dass es zwar auch Hänger im FF gab, aber zu anderen Zeiten wie im Chrome. Da habe ich dann erst gemerkt, dass da irgendwas oberfaul ist. Dann habe ich im Chrome-Debugger festgestellt, dass der ja gar nicht auf FHEM oder den Raspi wartet, sondern STALLED. Warum das?? Tja es war der DNS der Fritzbox, der hatte nämlich beide Raspis unter "fhem" angelegt und hat die nun hübsch zufällig per Round-Robin zurückgeliefert. Ich greife über fhem.fritz.box auf FHEM zu. Wenn er den Alten geliefert hat, der ja offline ist, gab es halt einen "Hänger". Problem gefixt und ZACK rauscht es wieder. Dank des neuen Raspis und meiner zahlreichen anderen Optimierungen in der Hoffnung das Problem zu finden auch noch viel schneller als sonst. Als Strafe mache ich heute keine Perl-Witze mehr .

Gruss Frieder

[rudolfkoenig]

Ist damit ein Fritz!BOX-Bug, oder?

[farion]

Naja oder ein Feature ... es waren halt zwei MACs mit gleichem Namen eingetragen ... der Name war ja implizit von mir angegeben, also am Ende mein Fehler. Das Verhalten ist eigentlich schon richtig ... ein "grosser" DNS macht das ja auch so ... mehrere A-Records => Round-Robin.