[gelöst] Fhem crasht nach 30 Sekunden

[rudolfkoenig]

Ok, hier ein paar mehr, weil die Pings in den letzte Zeilen interessierten sicher nicht:

Waren das die allerletzten Zeilen im Terminal?

[Wernieman]

Das wundert mich auch .. scheint mittendrin abzubrechen ...

[oldscout]

Ja, der Screenshot war vom ersten Crash-Tag, Rudolf hatte recht, das waren nur forks.
ich kille alle Prozesse vor dem Neustart, wenn vorhanden.

Ja, der Abbruch erfolgt einfach nur so, im Log des SQL sind alle Queries bis dahin zu sehen.

[oldscout]

Nachtrag heute nachmittag:

Eine Frage vom Anfang bleibt bisher unbeantwortet: Wie kann man ein device von aussen disablen?
Hat da mal jemand etwas kreiert?
Würde es genügen, in der fhemconfig bei dem device und der "0"-Konfigurations-UUID das Attribut disable zu setzen??

@Rudolfkoenig:
ja das sind die letzten Log-Zeieln gewesen.

das macht es so schwierig, in der DB sind nur (?) 1,8 Mio Datensätze, kann alle lesen.
Die fhemstate-Tabelle hingegen ist leer, obwohl beim debuggen setstates durchlaufen ?!?

[betateilchen]

Würde es genügen, in der fhemconfig bei dem device und der "0"-Konfigurations-UUID das Attribut disable zu setzen??

Das würde aber das Anlegen des device trotzdem nicht verhindern. Außerdem weißt Du ja gar nicht, welches Device "schuld" ist, weil der Abbruch nach Deiner Aussage immer zu unterschiedlichen Zeitpunkten passiert.

Die fhemstate-Tabelle hingegen ist leer,

Das ist normal.

Von einem manuellen Rumpfuschen in der Konfigurationsdatenbank würde ich dringend abraten.

[oldscout]

Ich will auch nicht unbedingt daran "rumpfuschen".
Aber wie komme ich weiter?
Hier geht einiges nicht mehr, kein "Automatismus" mehr....
Bei Null anfangen?
DB umkopieren?!? neustart? Plan C!

[rudolfkoenig]

Dass FHEM stirbt, und weder im Log, noch im Terminal die Ursache zu finden ist, ist ungewoehnlich, ich habe es bisher nicht erlebt.

Kannst Du bitte im Terminal, wo FHEM mit "perl fhem.pl -d configDB" gestartet wurde, nach dem FHEM-crash "echo $?" ausfuehren, und das Ergebnis hier zeigen? Und wenn die letzten Zeilen im Terminal diesmal was Anderes zeigen, dann auch die bitte.

Die naechste Stufe waere FHEM mit strace zu starten: "strace -o /tmp/xy -f perl fhem.pl -d configDB". Die Debug-Ausgabe liegt in /tmp/xy, und ist vmtl. groesser, als das mir Lieb ist. Die letzten Zeilen in dieser Datei enthalten die Ursache des Terminierens. Ob man das sinnvoll interpretieren kann, ist eine andere Frage.

[oldscout]

hier der Screenshot, leider auch zuletzt nur die pings, ganz unten das Echo $?
Das Trace starte ich noch.

[rudolfkoenig]

hier der Screenshot, leider auch zuletzt nur die pings, ganz unten das Echo $?

Ich habe Schwierigkeiten das Ergebnis von "echo $?" zu erkennen.
Wg. strace: vmtl. braucht man die komplette Datei, da geforkte Prozesse den Urspruenglichen ueberleben koennten.
Am besten komprimiert und irgendwo hochgeladen.

[oldscout]

Oh entschuldige, der screenshot war sehr knapp, da stand unten nur eine "1"......

[rudolfkoenig]

exit(1) wird von FHEMWEB, telnet und MQTT2_SERVER ausgefuehrt, falls beim FHEM-Start (und nur da) der Server-Port nicht geoeffnet werden kann. Das wird zwar vorher mit einer Fehlermeldung angekuendigt, diese kann aber bei den Ausgaben der Hintergrundprozesse untergehen.
Falls die Meldung "Server started with ..." im Log erscheint, dann ist dies sicher nicht der Fall, da der Start damit abgeschlossen ist.

[oldscout]

"server started..." steht drin,
habe heute Backup von WE zurückgeholt, gleiches Problem. Das letzte was zu sehen ist sind die Ping Abfragen.
@Rudolfkoenig: Das trace ist elendig lang. Möchtest Du es haben?

Ich werde die Pings jetzt rausoperieren aus der config. Was soll denn noch passieren Backup ist da. Ich werde sehen. Schlimmer kanns ja nicht mehr werden, ich stehe kurz vor der Kapitulation!! Schade!!

[rudolfkoenig]

@Rudolfkoenig: Das trace ist elendig lang. Möchtest Du es haben?

Ich habe leider diese Woche keine Moeglichkeit es zu analysieren. Danach gerne.

[oldscout]

Hallo,
Problem gelöst.
Durch das Debugging, dank an Rudolf König, die Varianten kannte ich bisher nicht, waren zuletzt Pings zu sehen, nachdem ich die "rausoperiert" hatte, startete Fhem erstmal wieder. Da es aber nicht die einzigen Presence-Abfragen waren, mußte es noch ein anderes Problem sein. Ich konnte ja wieder ins eigentliche Log schauen.
Aus mir unerklärlichen Gründen hatte der "freezemon" seine Einträge in der Log hinterlassen. Das Modul habe ich schon ewig deaktiviert in der Config drin stehen gelassen.
Ich habe nochmal ein Backup der Config zurück geholt, die Presence-Pings drinstehen lassen und nur den "freezemon" gelöscht und siehe da..... alles wie gewohnt.
Nun könnte jemand sagen: selbst schuld. Nein, das Modul war wie gesagt ewig drin, auch ein Start mit einer älteren Config brachte nichts, da dies ja in allen drin stand.
Ein Wunsch an die Entwickler:
Ein Tool welches auf der CLI ein Gerät sauber aus der letzten Config löscht ev. Abhängigkeiten auflistet.
z.B.
dev-delete <list> oder < delete>
welches mit den Zugangsdaten aus der Configdb.conf arbeitet.

Danke und schöne Woche an alle "Leser".... und Kommentatoren natürlich.

[betateilchen]

Ein Wunsch an die Entwickler:
Ein Tool welches auf der CLI ein Gerät sauber aus der letzten Config löscht ev. Abhängigkeiten auflistet.

Zumindest für Nutzer der configDB geht das ab heute:

https://forum.fhem.de/index.php/topic,128400.0.html