Absturz bei "rereadcfg"

[Dennis D.]

Hallo zusammen,

seit ein paar Versionen habe ich ein Problem mit FHEM. Und zwar stürzt FHEM (fast immer) ab, wenn ich in die Befehlszeile ein "rereadcfg" eingebe und vorher halt per FTP eine *.cfg geändert habe. Dies ist recht ärgerlich, weil ich dann halt immer per Konsole FHEM neu starten darf und vor beenden des Telnet-Clients mit "shutdown restart" einen Neustart auslösen muss, damit FHME nicht mit dem Telnet-Clienten beendet wird.

Hat sonst noch jemand dieses Problem?

Gruß,
Dennis

[Puschel74]

Hallo,

welchen Client verwendest du?

FHEM hat sich bei mir noch nie mit dem Telnet-Client beendet.

Grüße

[justme1968]

ja. 100% reproduzierbar auf meiner synoology diskstation. nach rereadcfg beendet sich fhem mit der telnet port fehler meldung immer. egal ob per web oder per telnet eingegeben. ein shutdown restart führt in etwa 5-10% zum gleichen fehler.

ich habe im code auch nirgends eine stelle gefunden wo der telext server port wieder zu gemacht wird.

gruss
  andre

[Dennis D.]

@Puschel,

verwende PuTTY. Log ich mich damit auf die Konsole meiner Qnap ein und starte FHEM und beende PuTTY mit exit, dann beendet sich auch FHEM, bzw. ist übers WebIf nicht mehr erreichbar. Daher mache ich zunächst immer ein "shutdown restart" bevor ich PuTTY beende.

@justme,

GENAU DAS stimmt mit meinem Problem überein. Speziell das mit dem "shutdown restart" habe ich auch in 5-10% der Fälle. Da bisher anscheinend keiner dieses Problem hatte, könnte es vielleicht mit der NAS zusammenhängen? Die meisten haben ja FHEM auf der Fritzbox oder dem Raspberry laufen.

Wie gesagt ist es erst seit ein paar Versionen. Vielleicht seit etwa zwei Wochen.

Gruß,
Dennis

[Reinerlein]

Hallo Dennis,

ich kann zwar nicht viel zum eigentlichen Thema beitragen, allerdings sieht mir dein im letzten Post beschriebenes Verhalten für Linux normal aus.

Prozesse werden immer als Fork des aktuellen Prozesses gestartet, und liegen damit in der Hierarchie unter dem aktuellen. Du startest FHEM also als Unterprozess deiner Kommandoshell.
Normalerweise werden beim Beenden einer Shell alle Unterprozesse mit beendet, damit keine Komandoleichen rumliegen, deren Ergebnis sowieso keiner mehr sehen kann.
Das nennt man "Hangup" und wird über das Signal "HUP" gesendet und verarbeitet.

Entsprechend kann man mit dem Befehl "nohup" einen Prozess starten, der nicht auf dieses Signal reagieren wird, da das Programm "nohup" dieses einfach "verschluckt".

Du müsstest FHEM also in der Konsole ungefähr so starten:

Code Auswählen Erweitern

nohup perl fhem.pl fhem.cfg &Das "&" am Ende der Zeile startet den Prozess im Hintergrund, das nohup sorgt dafür, dass dieser nicht durch schließen der Shell (sprich: trennen deiner Putty Verbindung) beendet wird.
Unter Umständen musst du natürlich noch Pfade mit angeben, dass kann ich dir von hier nicht sagen.

Versuch das mal...

Grüße Reinerlein

[Dennis D.]

hallo Reinerlein,

Danke, dass werde ich mal probieren und würde mir zumindest nen "shutdown restart" ersparen.

Zum "rereadcfg" Problem hast du aber keine Idee, oder?

Gruß,
Dennis

[Reinerlein]

Hi Dennis,

dazu müsstest du vielleicht mal deine Config (so minimal wie möglich, wo das Problem aber noch auftritt) und eine 5er Logausgabe, wenn das Problem aufgetreten ist, hier posten.

Ich habe das Problem selber nur bei meinem eigenen Modul. Du benutzt nicht zufällig das Sonos-Modul, oder? :-)
Bei mir ist das eine Thread-Problematik.

Aber es kann prinzipiell an vielen Dingen hängen, deshalb die notwendigen Daten...

Grüße Reinerlein

[Lix]

Hallo,

leide seit einigen Tagen auch unter diesem Problem. Ich nutze die Synology DS411.
Welches Perl nutzt ihr? Die Pakete von Martin Fischer oder IPKG? Mir kommt es nämlich so vor, dass diese Fehler auftreten, seit ich auf die IPKG Version umgestiegen bin.

Gruß,
Lix

[ingmar]

Hallo,
Auch bei mir kann ich das gleiche Verhalten seit ca. zwei Wochen bestätigen. Ich hab keine Ahnung was sich seit dem geändert hat. Es ist egal welche *.cfg ich über Web editiere, in 20% der Fälle beendet sich der "perl fhem" prozess.
Ich starte dann fhem wieder mit "service fhem start".

Gruß Ingmar

[rudolfkoenig]

Das Problem mit solchen Meldungen ist, das keiner helfen kann, da es keine Anleitung zum reproduzieren enthaelt.

Btw. ich finde das Editieren der fhem.cfg + rereadcfg grausam, da es zu viel ueberfluessiges macht,
man sollte stattdessen die einzelnen Geraete modifizieren (Detail-Ansicht, DEF, modify).

Das beste waere vmtl. rereadcfg komplett zu entfernen.

[Lix]

Das stimmt natürlich, aber irgendwann möchte man ja auch die Änderungen der einzelnen Devices in die FHEM.cfg speichern.
Ich weiß nicht ob es schon immer so war, jedenfalls wenn ich die FHEM.cfg speichere, wird anschließend automatisch eine Neuinitialisierung durchgeführt bei der dann der Prozess manchmal abstürzt, so wie bei rereadcfg.
Ich bilde mir aber ein, das save fhem.cfg früher kein Neueinlesen der fhem.cfg zur Folge hatte...

[ingmar]

Hallo,
Ich hab das nochmal nachgestellt.  (mit "global verbose 5")
Nach zweimaligem 'rereadcfg' kam schon der Absturz.

letzte Logeinträge:
2013.04.10 10:25:27 5: Cmd: >define telnetPort telnet 7072 global<
2013.04.10 10:25:27 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.
2013.04.10 10:25:27 5: PRESENCE (BueroComputer) - ping command returned with output:
PING 192.168.0.104 (192.168.0.104) 56(84) bytes of data.
64 bytes from 192.168.0.104: icmp_req=1 ttl=128 time=0.640 ms
64 bytes from 192.168.0.104: icmp_req=2 ttl=128 time=0.603 ms
64 bytes from 192.168.0.104: icmp_req=3 ttl=128 time=0.669 ms
64 bytes from 192.168.0.104: icmp_req=4 ttl=128 time=0.628 ms

--- 192.168.0.104 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.603/0.635/0.669/0.023 ms

2013.04.10 10:25:52 1: Including fhem.cfg


Jetzt habe ich die PRESENZ defines auskommentiert und habe 10 x rereadcfg eingegeben und keinen Absturz hinbekommen.
Ich werde es weiter beobachten, aber ich denke es hängt irgendwie an der PRESENZ Funktion.

Gruß
Ingmar

[Markus Bloch]

Hallo Ingmar,

im Bezug auf PRESENCE habe ich in den letzten Tagen Verbesserungen eingebracht, die einen solchen Absturz verhindern sollen.

Bitte führe mal ein Update durch und starte FHEM komplett neu.

Falls es immer noch reproduzierbar ist, währe die Perl-Fehlermeldung interessant, warum er abstürzt. Diese wird aber leider nicht in der fhem.log festgehalten, sondern auf der Konsole ausgegeben von der FHEM gestartet wurde.

Viele Grüße

Markus

[ingmar]

Hallo Markus,
Vielen Dank für den Hinweis auf meine veraltete Version. Jetzt habe ich auf 5.4 hochgezogen und es scheint zu funktionieren.
Sorry, ich kann mir gut vorstellen, das Entwickler genervt sind, wenn immer wieder auf Fehler in veralteten Versionen aufmerksam gemacht werden.... ich gelobe Besserung.

Viele Grüße
Ingmar

Danke auch für den Hinweis mit der Konsole...

[rudolfkoenig]

> Ich bilde mir aber ein, das save fhem.cfg früher kein Neueinlesen der fhem.cfg zur Folge hatte...

Das bilde ich mir auch ein. Und hoffe stark, dass es immer noch so ist.