[gelöst] FHEM Absturz nach rereadcfg

[Schlimbo]

Hallo,
ich habe FHEM auf einen Raspberry Pi installiert und das System läuft mittlerweile seit mehreren Monaten ohne Probleme  seit einigen Tagen stürzt FHEM bei der Eingabe von rereadcfg ab.
Im logfile steht: "can't open server port at 7072: Address already in use.  Exiting."

Kann mir jemand einen Tipp geben wie ich herausfinden kann woran das liegt?

Starte ich FHEM danach aus der Konsole mittels " /etc/init.d/fhem start" läuft wieder alles ganz normal.

[rudolfkoenig]

Einer der FHEM-Module hat geforkt (d.h. einen zweiten Prozess gestartet), und dieser zweite Prozess hat das telnetPort nicht zugemacht. Beim rereadCfg schliesst der "richtige" FHEM Prozess alle Ports, und oeffnet sie diese neu. Leider kann telnet seinen eigenen Port nicht oeffnen, weil der zweite Prozess (der immer noch lebt), sie belegt. Um nicht unerreichbare Prozesse zu haben, beendet telnet diesen FHEM.
Loesung: das geforkte Modul ausfindig machen, und den Maintainer ueberreden, alle Server Ports zu schliessen.

[betateilchen]

Das identische Problem wurde in den letzten Tagen hier im Forum schon öfters beschrieben. Irgendein Modul wurde wohl kürzlich dahingehend verändert, denn in einer solchen Häufigkeit trat dieses Problem bis dahin nicht auf.

Könnte das mit den kürzlich gepachten TcpServerUtils.pm zusammenhängen? (Reine Vermutung)

[rudolfkoenig]

Nur sehr indirekt, die TcpServerUtils.pm Aenderungen haben nur zusaetzliche Funktionen fuer korrektes SSL Schreiben hinzugefuegt.
@Schlimbo: kannst du die Liste deiner Module hier posten, damit wir das Modul mit fork finden?
Du darfst diese Suche natuerlich auch selbst durchfuehren

[betateilchen]

@Schlimbo: kannst du die Liste deiner Module hier posten,

Die Liste bekommst Du am einfachsten, wenn Du in der fhem-Befehlszeile ein "fheminfo" eingibst. Wichtig ist der Ausgabeteil "Defined modules"

Code Auswählen Erweitern


Defined modules:
  FHEMWEB    : 7
  FileLog    : 1
  I2C_BMP180 : 1
  RPII2C     : 1
  at         : 5
  cmdalias   : 1
  configDB   : 1
  telnet     : 1


[rudolfkoenig]

...oder "version"

[betateilchen]

ja, aber fheminfo finde ich "übersichtlicher"

[Schlimbo]

Danke für die Antworten.

Hier der Output von fheminfo:

Fhem info:
  Release  : 5.6
  Branch   : DEVELOPMENT
  OS       : linux
  Arch     : arm-linux-gnueabihf-thread-multi-64int
  Perl     : v5.14.2
  uniqueID : 
  upTime   : 15:00:11

Defined modules:
  CUL            : 1
  CUL_MAX        : 1
  Calendar       : 1
  ENIGMA2        : 1
  FB_CALLMONITOR : 1
  FHEMWEB        : 9
  FLOORPLAN      : 1
  FileLog        : 30
  JeeLink        : 2
  LaCrosse       : 1
  MAX            : 16
  PCA301         : 10
  PHTV           : 1
  PRESENCE       : 3
  RPI_GPIO       : 11
  SVG            : 15
  SYSMON         : 1
  THRESHOLD      : 1
  Text2Speech    : 1
  Twilight       : 1
  Weather        : 1
  XBMC           : 1
  YAMAHA_AVR     : 2
  at             : 4
  autocreate     : 1
  dummy          : 23
  eventTypes     : 1
  notify         : 18
  readingsGroup  : 4
  remotecontrol  : 1
  telnet         : 1
  watchdog       : 1
  weblink        : 3

Defined models per module:
  ENIGMA2        : duo2
  JeeLink        : [pcaSerial.10.1]
  YAMAHA_AVR     : RX-V773

Gruß Schlimbo

[Schlimbo]

Zur Info noch:

ich habe zum testen mal "define telnetPort telnet 7072 global" aus der fhem.cfg herausgenommen,
dann verursacht "define WEB FHEMWEB 8083 global" den Fehler beim öffnen des Ports 8083, also wird dieser anscheinend auch nicht richtig  geschlossen.

Bei einem "shutdown restart" tritt dieses Problem jedoch nicht auf, werden bei einen shutdown die Prozesse anders beendet als bei rereadcfg?

[betateilchen]

Ein rereadcfg beendet keine Prozesse.

[rudolfkoenig]

Ich tippe auf XBMC mit "attr XXX fork enable", das muesste der Modulautor fixen. Ansonsten kommen PRESENCE und Text2Speech in Frage, wenn das einer der beiden ist, dann muss ich das vermutlich in Blocking.pm fixen.

@Schlimbo: Kannst du das bitte pruefen, indem du diese Module eins nach dem anderen auskommentierst, um rereadcfg zu testen?

[Schlimbo]

es war wirklich das Attribut  "attr XXX fork enable" bei XBMC, das hatte ich vor einiger Zeit gesetzt und ganz vergessen, hätte ich eigentlich selber drauf kommen müssen.

Vielen vielen Dank für die Unterstützung, finde den Support hier im Forum echt spitze.

[Schlimbo]

zur Info noch:
in dem Thread http://forum.fhem.de/index.php/topic,10075.msg235775.html#msg235775l
gibt es eine Version, in der das "fork Problem" gefixt wurde.

[Rince]

Ich tippe auf XBMC mit "attr XXX fork enable", das muesste der Modulautor fixen

Das Modul ist verwaist. Vbs versucht schon seit geraumer Zeit, Maintainer zu werden...
Er hat auch das Probkem gelöst...

[P.A.Trick]

Sollte nun gefixt sein...VBS ist neuer Maintainer und hat es bereits eingecheckt!