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

[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:

Code Auswählen Erweitern


   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.

Code Auswählen Erweitern

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)

Code Auswählen Erweitern

netstat -lntp

So sind die Infos etwas "dürftig" ...

[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 .

[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

[Beta-User]

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).

[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

[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.

[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

[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!

[Det20]

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.

[Det20]

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

Code Auswählen Erweitern


  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.

Code Auswählen Erweitern


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).

[rudolfkoenig]

dnsServer ist nur fuer HttpUtils_NonblockingGet relevant.

Gibt 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]

Bei system kann man ein & hinten anhaengen

?