[Gelöst] FHEM mehrfach geladen, startet aber nicht

Begonnen von Det20, 19 Mai 2019, 21:32:18

Vorheriges Thema - Nächstes Thema

Det20

Hallo zusammen,

nun hat es mich auch mal erwischt. FHEM semmelt irgendwann ab und ist auf Port 8083 nicht mehr erreichbar, und zwar so 2-3 Minuten nach Start. Bei der Suche habe ich verbose auf 5 gestellt und siehe da ... Das LOG wird weiterhin genauso gefüllt, als würde FHEM laufen, nur reagiert es halt auf 8083 nicht mehr. In der Prozessliste sieht es so aus:


   3300 fhem 21:06 perl fhem.pl fhem.cfg
      3333 fhem 21:06 fhem-connect
      4787 fhem 21:23 perl fhem.pl fhem.cfg
      4791 fhem 21:23 perl fhem.pl fhem.cfg
      4868 fhem 21:25 perl fhem.pl fhem.cfg
      4974 fhem 21:27 perl fhem.pl fhem.cfg


Mir will die Logik nicht so ganz einleuchten. Wie arbeiten denn die einzelnen Prozesse zusammen? Irgendein FHEM muss ja arbeiten, schließlich wird das LOG ja gefüllt. Nur anscheinend nicht das FHEM, das auf 8083 reagiert. Raffe ich nicht ... Und vor allem: Wie finde ich raus, weshalb es Probleme gibt, wenn irgendein FHEM weiterläuft und munter das LOG füllt? Dann gibt es keine letzte Zeile, anhand der ich erkennen kann, was da los ist.

ps aux | grep [f]hem findet Prozesse

Vor einigen Wochen gab es mal einen Bug, bei dem FHEM lahm gelegt wurde, wenn sehr sehr viele Devices angelegt waren, finde aber leider den Thread nicht mehr

Wernieman

1. Gib uns doch mal den Output (als root) von "ps aux | grep [f]hem"
2. Was hört alles auf welchen prots (als root) netstat -lntp

So sind die Infos etwas "dürftig" ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

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

Beta-User

Das hier hast du durchgearbeitet: https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche?

Ansonsten bitte nochmal vergegenwärtigen, dass die Serverkomponente fhem.pl und die Web-Serverkomponente FHEMWEB zwei Dinge sind, von denen das eine (fhem.pl) sehr wohl ohne das andere kann ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rischbiter123

Moin,

kann zwar leider nichts zur Aufklärung beitragen, hatte das Problem aber nach dem gestrigen Update auch. Fhem lief als Server (systemcl status fhem), aber war über Web nicht erreichbar. Nach einem Restore läuft alles wieder.

LG

Andreas
4*Raspi, Max Thermostate und Fensterkontakte, FB7590, Mysensors und NanoCUL, IT und Sonoff, zigbee2mqtt2

Beta-User

Zitat von: rischbiter123 am 20 Mai 2019, 12:13:50
hatte das Problem aber nach dem gestrigen Update auch. Fhem lief als Server (systemcl status fhem), aber war über Web nicht erreichbar.
War irgendwas im Log ersichtlich, was FHEMWEB oder allowed betrifft?
Ich kann im svn nichts an Änderungen (die letzte Woche) nachvollziehen, was damit im Zusammenhang stehen könnte, und ihr scheint die einzigen zu sein, die das betrifft (wenn es überhaupt dasselbe ist).

Bitte um Info auch zu den funktionierenden/nicht funktionierenden Versionen, sonst kann niemand das fixen, wenn es denn tatsächlich ein Problem geben sollte (was ich im Moment noch nicht glaube).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rischbiter123

Moin,

im Log (über Winscp nachgesehen) war nichts auffälliges. Ist allerdings auch nur Verbose 2.
Die bei mir funktionierende Version ist: fhem.pl:19381/2019-05-13
Mehr kann ich leider nicht beitragen, da ich, wie geschrieben, ein Restore gemacht habe und es jetzt wieder funktioniert.

LG

Andreas
4*Raspi, Max Thermostate und Fensterkontakte, FB7590, Mysensors und NanoCUL, IT und Sonoff, zigbee2mqtt2

Beta-User

Das ist die aktuelle Version im svn. An fhem.pl liegt es also nicht...

Die letzte svn-Aktualisierung von FHEMWEB war Anfang März; das wird es also auch nicht sein.

@rischbiter123: Bitte entschuldige, aber m.E. ist so ein Vorschlag zum downgrade sehr voreilig und insgesamt wenig hilfreich, da nicht geeignet, die eigentliche Ursache zu finden. Das sollte man wirklich erst in Betracht ziehen, wenn es eindeutig ist, dass sich ein Problem nur so (erst mal) umgehen läßt. Ist es aber m.E. nicht.

Für den Fall, dass du mithelfen willst, diesen oder ggf. einen anderen Fehler zu lokalisieren, wäre evtl. ein höherer Verbose-Level sinnvoll ;) . (Ansonsten hätte mich noch interessiert, wie die weitere Strategie gewesen wäre; du wirst ja kaum vorgehabt haben, dauerhaft beim jetzigen Versionsstand zu bleiben).

Ansonsten warten wir mal drauf, was der TE zur Erhellung beitragen kann.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rischbiter123

Moin,

hatte es erst gestern Abend gemerkt und da war es, für mich, erst mal der schnellste Weg, um Fhem -hoffentlich- wieder zum Funktionieren zu bringen. Bei Misserfolg hätte ich den Verboselevel hochgesetzt, da ich nach einem Neustart jeweils für ca. 1 Minute rangekommen bin. Scheint dann ja wahrscheinlich eins der von mir benutzten Module zu sein. Liege aber im Moment flach und habe daher keinen Nerv, es auszuprobieren.

LG

Andreas
4*Raspi, Max Thermostate und Fensterkontakte, FB7590, Mysensors und NanoCUL, IT und Sonoff, zigbee2mqtt2

Beta-User

Kein Ding, manchmal darf es auch ein Quickfix sein :) .

Wenn du irgendwann weitere Erkenntnisse hast (so die dann nicht schon wieder veraltet sind): Laß hören.

Ansonsten erst mal gute Besserung!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Det20

#9
Sodale, nachdem ich nicht mehr Herr der Lage geworden bin, habe ich erstmal nahezu alle Devices, Dummys, DOIF's usw aus der CFG rausgeworfen und dann Stück für Stück wieder hinzugefügt. So wie es aussieht, ist es das SkyQ Modul. Habe ich das Device hinzugefügt, hing alles. Habe ich es entfernt, lief alles. Soweit, sogut. Komisch ist nur, dass heute alles läuft, selbst wenn das Device hinzugefügt und aktiviert ist.

Ich habe letzte Nacht noch 3-4 Dummy-Devices gelöscht, die ich nicht mehr brauche. Angefangen hat der Spuk am 6.5. aber fragt mich nicht, was ich da genau getan habe. Ich ändere regelmäßig was.

Habe nun mal testhalber 10 Dummy Devices hinzugefügt, trotzdem hängt FHEM nicht, selbst wenn SkyQ aktiviert ist. Sehr komisch das alles und macht mir ein wenig Angst. Ohne zu Wissen was da los war, fährt man nicht ruhigen Gewissens in den Urlaub und überlässt FHEM die Steuerung.

Beta-User

Wenn das SkyQ-Dingens irgendein Netzwerkgerät ist, kann das schon die Ursache gewesen sein, evtl. weil ein blockierender HTTP-Request ins Leere geht. Dann müßte aber auch im Log eine Logik erkennbar sein, von wo ggf. nichts mehr kommt (fork-Prozesse füllen weiter fleißig das Log, aber die Hauptschleife "hängt").

M.E. liegt es nicht an irgendeiner Zahl der Devices (wir hatten hier schon Installationen mit 3.000+ Devices...), allenfalls Speicher könnte ein Thema sein oder die Last, die die Devices im Einzelnen erzeugen (v.a. iVm. ungenauen Trigger-Vorgaben für notify/DOIF/userreadings usw); das ist aber ein anderes Thema.

Schau mal in global nach dns-irgendwas. Kann bei Netzwerkproblemen/-blockaden helfen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Det20

#11
Falls es überhaupt die SkyQ ist. Habe mir die mal näher angeschaut, es gibt eigentlich nur zwei kritische Punkte:


  my $ip = AttrVal($hash->{name}, 'ip', undef);
  my $url = "http://$ip:9006/as/system/information";
  my $r = HTTP::Request->new('GET', $url);
  my $ua = LWP::UserAgent->new();
  my $res = $ua->request($r);


Würde aber irgendwann in einen Timeout laufen, kann es eigentlich nicht sein.


system("sky-remote-cli $ip $opt");


Tippe ich eher drauf, weiß nicht so genau, ob die nen Timeout verkraften. https://github.com/dalhundal/sky-remote-cli

Gibt es für die beiden Punkte die Möglichkeit, einen vernünftigen Timeout drumrum zu bauen?

Beta-User

Hast du in global dnsServer gesetzt?

Wenn nein: wäre es nicht sinnvoll, das zu testen?

Ansonsten ist das ja ein neues, eher experimentelles Modul => ggf. in dem passenden Thread mal fragen (aber erst, wenn dnsServer nicht hilft).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

#13
dnsServer ist nur fuer HttpUtils_NonblockingGet relevant.
ZitatGibt es für die beiden Punkte die Möglichkeit, einen vernünftigen Timeout drumrum zu bauen?
Bei system kann man ein & hinten anhaengen, bei HTTP::Request faellt mir nur BlockingCall oder HttpUtils_NonblockingGet ein


Det20


CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Det20


rudolfkoenig

system() fuehrt das Argument mit shell aus, falls ein verdaechtiges Zeichen (>, &, etc) sich drin befindet.
Im shell bedeutet & Trennzeichen und Programm im Hintergrund ausfuehren.
Habe nie behauptet, dass es Nebenwirkungsfrei ist.

CoolTux

Da Du anscheinend das Problem auf SkyQ eingrenzen konntest ist meine persönliche Meinung folgende.
Das Modul ist nicht offiziell, also kein Teil von FHEM. Daher sehe ich mich persönlich jetzt nicht angesprochen da was machen zu müssen. (Nicht falsch verstehen ich wollte das nur mal erwähnen)
Meine Empfehlung. Melde Dich beim Entwickler von dem SkyQ Modul. Gerne kann sich der Entwickler bei Fragen zu FHEM Modul Entwicklung an die FHEM Community wenden.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Det20

Erstmal vielen Dank an alle. Ich vermute mal, dass es 48_SkyQ war, kann das Problem allerdings nicht mehr nachvollziehen, sprich: Im Test habe ich das Modul aktiviert, 50 Dummy-Devices angelegt und nix ist passiert. Würde nur gerne ev Fehler korrigieren, wenn es SkyQ war. Der Entwickler meldet sich leider nicht mehr, muss also mit dem leben was ich habe.

Wollte eigentlich und ursprünglich auch nur verstehen, wie Main- und Fork-Prozesse zusammen arbeiten.

CoolTux

Zitat von: Det20 am 21 Mai 2019, 09:45:11
Der Entwickler meldet sich leider nicht mehr, muss also mit dem leben was ich habe.
Wollte eigentlich und ursprünglich auch nur verstehen, wie Main- und Fork-Prozesse zusammen arbeiten.

Naja das ist ja Unsinn. Wir leben in der Open Source Welt. Wenn es Dir wirklich wichtig ist und Du da Interesse hast dann Forke das Modul und schreibe es schöner.
Und NEIN ein ich kann nicht programmieren zählt nicht  ;D Wer wirklich etwas will schaft es auch. (eigen Erfahrung)


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Det20

Habe es ja schon an meine Anforderungen angepasst (siehe SkyQ Thread). Wollte nur den Timeout Part angehen und fand die Lösungen, die im Web so angeboten werden, nicht sehr kompfortabel gelöst. Aber manches ist in Perl halt wirklich nicht schön gelöst, manches andere dafür schon. Muss man mit leben.

Beta-User

Kann nicht beurteilen, ob das ein "Perl-Problem" ist, aber anbei mal eine etwas überarbeitete Fassung auf Basis deiner Modifikationen. Im Prinzip ist es etwas "gesäubert" und der Rückgabeprozess nach dem "system()"-Aufruf asynchron ausgelegt.

Ich kenne mich mit den HttpUtils nicht aus, aber der Spur nach könnte das eigentlich aaO. ein Einstieg sein.

Ggf. viel Spaß beim Durchschauen der Änderungen und (hoffenlich) lernen (hoffentlich, weil ich auch kein Experte bin, muß nicht funktionieren...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Ich habe auch einen Patch eingereicht im SkyQ Thread  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Zitat von: CoolTux am 21 Mai 2019, 10:33:32
Ich habe auch einen Patch eingereicht im SkyQ Thread  ;D
Sieht auch nicht schlecht aus...  ;D

(War mir erst mal nicht aufgefallen, dass die undef-fn nicht aktiviert war... Wer macht denn sowas ??? .)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Det20

#25
Hammer! Vielen Dank, versuche mal, beide Versionen zusammenzuführen.
Was mit bei der asynchronen SYSTEM() Lösung gerade einfällt: Bleiben, wenn das schief geht und sich der "andere" Prozess aufhängt, nicht mit der Zeit x Leichen im Speicher hängen?

CoolTux

Müsste man Mal schauen ob man das besser hin bekommt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net