Start von FHEM mit configdb hängt

[Muschelpuster]

Moin zusammen,

Bei mir ist es wie immer: ich habe nichts gemacht 
Aber im Ernst - Updates habe ich in der letzten Zeit vernachlässigt und die letzte Änderung am FHEM ist auch schon gut eine Woche her.
Trotzdem hat FHEM heute morgen den Betrieb eingestellt. Zuerst lief es noch, wie die Reaktionen diverser Bewegungsmelder zeigten und plötzlich hing alles. Auf dem Sprung zur Arbeit habe ich nochmal schnell hilfloses Verhalten gezeigt und FHEM neu gestartet. Zumindest war das mein Wille, laut Log hat FHEM da andere Vorstellungen, wie ich gerade nochmal nachgeprüft habe:

Code Auswählen Erweitern

2019.03.18 17:51:45 2: ESPEasy ESPBridge: Opening bridge port tcp/8383 (v1.38)
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/x86_64-linux-gnu/perl/5.24/Socket.pm line 157, <DATA> line 1.
Die Fehlermeldung hat nichts mit dem ESPEasy zu tun, da war ursprünglich ein anderes Modul davor, was ich in der Hoffnung einer schnellen Lösung einfach mal aus der DB geschmissen habe (war sowieso eine Karteileiche, die ich unter Verdacht hatte).
Wie man sieht war der Erfolg überschaubar.
Nun habe ich mal den Moment des Todes gesucht:

Code Auswählen Erweitern

2019.03.18 05:50:00 2: WEBIO_12DIGITAL set WebIO_out_00 on
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/x86_64-linux-gnu/perl/5.24/Socket.pm line 157.
2019.03.18 05:53:49 1: sip1[32022], can´t find my parent 717 in process list !
Died at ./FHEM/96_SIP.pm line 371.Auch die Löschung des SIP-Modules konnte mich nicht glücklicher stimmen...
Mit der Default-File-Konfig startet FHEM ebenso wie im ConfigDB-Rescue-Mode, nostate => 1 hilft nicht und auch verbose=5 zeigt mir keine bahnbrechenden Erkenntnisse.
Wie kann ich das Problem nun weiter eingrenzen? Mach es Sinn, FHEM erst einmal im Rescue-Mode upzudaten (fhem.pl = Rev. 16609)?

ratlose Grüße
Niels

[betateilchen]

Mach es Sinn, FHEM erst einmal im Rescue-Mode upzudaten (fhem.pl = Rev. 16609)?

Nein.

Die Fehlermeldung hat nichts mit dem ESPEasy zu tun,

Die Fehlermeldung hat auch nichts mit der configDB zu tun.

Da in beiden von Dir dokumentierten Fehlermeldungen das perl Modul "Socket" angemeckert wird,

Code Auswählen Erweitern


Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/x86_64-linux-gnu/perl/5.24/Socket.pm

Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/x86_64-linux-gnu/perl/5.24/Socket.pm


solltest Du Dich erstmal um die Basis in Deinem Betriebssystem kümmern, bevor Du versuchst, das Problem innerhalb von FHEM zu lösen.

Spontan würde ich vermuten, da wurde innerhalb des Betriebssystems ein update durchgeführt und dabei ist etwas schiefgegangen. Leider hast Du nichts zur konkreten Plattform geschrieben, aber sind in Deiner Plattform beispielsweise "unattended upgrades" aktiviert, wie z.B. bei Ubuntu?

[betateilchen]

schau mal hier: https://forum.fhem.de/index.php/topic,53406.0.html

Da gab es ähnliche Probleme letztes Jahr schonmal. Habe jetzt aber nicht den ganzen Thread durchgelesen.

Du kannst auch nach "Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 " googlen.

[Muschelpuster]

Danke Betateilchen,

Die Fehlermeldung hat auch nichts mit der configDB zu tun.

Schon klar, nur muss es ja erwähnt werden 
Interessant wäre hier ja, ob ich raus bekommen kann, in welcher Reihenfolge die Definitionen geladen werden, dann könnte ich mir gezielt das die Definition anschauen, bei der es kracht.

Da in beiden von Dir dokumentierten Fehlermeldungen das perl Modul "Socket" angemeckert wird, solltest Du Dich erstmal um die Basis in Deinem Betriebssystem kümmern, bevor Du versuchst, das Problem innerhalb von FHEM zu lösen.

Ja, auch da ist mir schon klar, dass der Fehler von dem Perl-Modul gemeldet wird. Aber das bedeutet ja noch nicht, dass diese nicht aus einem fehlerhaften Aufruf des Moduls resultiert.

Spontan würde ich vermuten, da wurde innerhalb des Betriebssystems ein update durchgeführt und dabei ist etwas schiefgegangen. Leider hast Du nichts zur konkreten Plattform geschrieben, aber sind in Deiner Plattform beispielsweise "unattended upgrades" aktiviert, wie z.B. bei Ubuntu?

Die Daten in meiner Signatur passen eigentlich. Ok, keine genaue Debian-Version, aber "unattended upgrades" habe ich nicht aktiviert (gerade nochmal geprüft).

schau mal hier: https://forum.fhem.de/index.php/topic,53406.0.html
Da gab es ähnliche Probleme letztes Jahr schonmal. Habe jetzt aber nicht den ganzen Thread durchgelesen.
Du kannst auch nach "Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 " googlen.

Danke für den Link, ich habe das komplett genossen und es waren interessante Dinge dabei, aber die entsprechenden Anpassungen haben mich auch nicht weiter gebracht.
Die Google-Ergebnisse sind eher was für Programmierer, die habe ich schon erfolglos bemüht.

unterbelichtete Grüße
Niels

[betateilchen]

Die Daten in meiner Signatur passen eigentlich.

Bei mir werden grundsätzlich keine Signaturen angezeigt, da steht einfach zuviel Quatsch drin, der nur Platz auf kleinen Monitoren verschwendet

Die Reihenfolge der devices würde Dir nicht weiterhelfen Es muss sich bei Deinem Problem um ein Gerät handeln, das eine Netzwerkverbindung braucht. Vermutlich trifft das auf mehrere Geräte zu, deshalb hattest Du die Meldung nach dem Löschen des ESPeasy anschließend bei einem SIP device.

[Muschelpuster]

Ok, Du gehst also davon aus, dass die Fehlermeldung schon zu der jeweils davor angezeigten Definition gehört? Aktuell hänge ich bei einer Reading Group...
Aber ja, auch wenn ich die älteste DB-Version starte kommt der Fehler, was natürlich auf das Betriebssystem / die Perl-Installation schließen lässt. Ich suche weiter.

generelle Grüße
Niels

[betateilchen]

Du gehst also davon aus, dass die Fehlermeldung schon zu der jeweils davor angezeigten Definition gehört?

Ja. Probier mal folgendes.

Starte FHEM mit einer möglichst leeren fhem.cfg und mache dann ein FHEM Update.
Danach wieder mit configDB starten und schauen, ob sich was geändert hat.

[Muschelpuster]

Hat nicht viel gebracht. So sieht es jetzt mit Verbose=5 aus:

Code Auswählen Erweitern

2019.03.18 21:20:53 5: Starting notify loop for rp_Terra_1, 1 event(s), first is off
2019.03.18 21:20:53 5: rg_battStatus: not on any display, ignoring notify
2019.03.18 21:20:53 5: End notify loop for rp_Terra_1
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/x86_64-linux-gnu/perl/5.24/Socket.pm line 157.


aktualisierte Grüße
Niels

[betateilchen]

tja... dann sehe ich jetzt zwei Möglichkeiten

1. Stück für Stück weiter probieren
2. Betriebssystem und FHEM neu aufsetzen und die Konfiguration danach wieder einspielen

Ich würde Variante 2 wählen, das hat bei mir bisher immer gut geholfen und war jeweils die schnellste Lösungsvariante.

[Muschelpuster]

Hmm Danke, das hört sich ja nicht so schön an. Ich habe mal versucht, FHEM von der Befehlszeile zu starten, das klingt ja noch irgendwie interessant:

Code Auswählen Erweitern

root@deb-srv:/opt/fhem# perl fhem.pl configDB.conf
Can't locate RTypes.pm in @INC (you may need to install the RTypes module) (@INC contains: . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at fhem.pl line 588.

Die Datei  /opt/fhem/FHEM/RTypes.pm existiert aber, aber wer ist @INC? Den String finde ich zwar in der fhem.pl, aber das hilft mir jetzt auch nicht weiter.

alternative Grüße
Niels

[betateilchen]

@INC ist eine perl Variable (eine Liste) in der die Pfade stehen, wo nach perl Dateien gesucht werden soll. Diese Variable kommt auch nicht aus FHEM, sondern ist auf Betriebssystemebene definiert.

Der Aufruf

Code Auswählen Erweitern

perl fhem.pl configDB.conf

ist falsch, falls Du damit die Absicht hast, FHEM mit der configDB zu starten.

Richtig wäre:

Code Auswählen Erweitern

perl fhem.pl configDB

[Muschelpuster]

Hey man muss sich nur mal daran erinnern, was man mal so alles gemacht hat. Wozu gibt es Datensicherungen 
Ich habe jetzt den letzten automatischen MySQL-Dump wieder in die DB gepumpt und FHEM rennt wieder. Also irgendwo gab es da wohl doch ein Problem in der Konfig. Warum auch immer. Nur die Readings sind alle schräg und die in den DoIf's eingestellten Zeiten sind weg - aber damit kann ich ja leben - so räume ich gleich mal wieder etwas auf.
Also Betateilchen, nochmal Danke für Deinen Input, ich gehe jetzt mal putzen.

Richtig wäre:

Code Auswählen Erweitern

perl fhem.pl configDB

Ah ok, ich dachte das wäre nur für die DB-Initialisierung, aber eigentlich klar, denn da steht ja nichts drin, was einer fhem.cfg auch nur ansatzweise ähnelt.

gelöste Grüße
Niels

[betateilchen]

Es wäre schon interessant zu wissen, was letztendlich das Problem war. Aber prima, dass Dein FHEM wieder läuft.

Trotzdem solltest Du vielleicht erstmal ein FHEM Update machen, bevor Du anfängst, Deine Installation weitergehend zu bereinigen.

[Muschelpuster]

Jo, Update war ja schon im Zuge des Leidens gemacht, das hat auch gehalten.
Leider ist die ganze Nummer inzwischen nicht mehr ganz trivial, aber mal sehen ob ich meine heutige DB-Sicherung mal in eine Spiel-VM laden kann. Aber dann werde ich sicher angemeckert, dass die ganzen IP-Devices nicht erreichbar sind und auch der fehlende Rademacher-Stick wird einen Fehler verursachen.

aktuelle Grüße
Niels