Hast du irgendwelche Fehlermeldungen?
paresy
nur die o.g. Meldung (bind …)
Andere Meldungen (unter /var/log) habe ich nicht mehr (nach dem reboot).
Ich kann gerne beim nächsten Mal etwas mehr prüfen / sichern
Ja. Magst du mal beim nächsten Auftreten in ssh ein lsof ausführen? Mich würde Interessieren wer den Port bindet/klaut.
paresy
klar, mach ich natürlich
1 „Gefällt mir“
Bei mir ist heute nach 3 Tagen wieder die Verbindung weg.
Anbei die Ausgabe, ich hoffe ich hab’s richtig gemacht !?
symbox.txt (18,8 KB)
Da sollte es um das gleiche Problem gehen…
https://community.symcon.de/t/probleme-mit-home-matic-schnittstelle-fehlerhaft/137781/5
so ähnlich hatte ich das vor Jahren auch mit Docker:
https://community.symcon.de/t/sockets-lassen-sich-nicht-mehr-neu-starten/122895
Habe seit einigen Wochen Probleme mit Home Matic,
Nach einigen Tagen ist die Schnittstelle fehlerhaft. Beim neu verbinden
Kommt folgende Fahlermeldung.
Neustart der Symbox löst das Problem für einige Tage .
Da steht kein Passwort eingetragen.
Vielleicht liegt es daran.
Es scheint ja irgendwas zum Abbruch der Verbindung du führen. Hast du mal geschaut wie oft die Verbindung abbricht?
paresy
Kann ich das Monitoren/ Logen ?
Das hab ich die Tage auch bei einem System.
Die Verbindung kann auch nicht wieder hergestellt werden ohne einen Neustart.
CCU-Neustart hilft nicht
Ihr seid alles SymBox Nutzer und ihr habt alle das Tailscale Modul in Verwendung, oder?
Symcon startet Tailscale. Unter Linux wird dies über Fork gemacht, dabei erbt aber Tailscale alle FDs. Wir geben den FD beim HM reconnect frei, aber der geerbte FB von Tailscale blockiert weiterhin den Port. Bei der exec Funktion von PHP können wir dort nicht viel beeinflussen (evtl. könnten wir PHP im Build Prozess patchen 
, aber das ist wieder eine wilder Patch). Zu IP-Symcon 7.2 haben wir IPS_Execute schon passend umgebaut, sodass ich zeitnah das Tailscale Modul darauf umbauen will. Dann sollte der Spuk aufhören.
Ich befürchte das Problem passt auch zu diesem Problem: https://community.symcon.de/t/v7-1-vom-02-02-24-symbox-fehlermeldungen/136455
Vermutlich hängt auch das hiermit zusammen: Freier Speicherplatz ist kritisch! Auch dort gibt irgendwer den FD nicht frei, sodass die eigentlich gelöschten Logfiles weiterhin auf der tmpfs Partition bleiben anstatt den Speicher frei zu geben.
Die Ursache ist also klar. Die Lösung leider nicht trivial. Ich bin aber dran.
paresy
Ja! Den Verdacht hatte ich auch schon!
Ich kann ja mal versuchen das Modul zu löschen.
Evtl. hilft das ja oder ist Wireguard im Hintergrund verantwortlich und es spielt keine Rolle ob das Taulscale-Modul installiert ist?
Es reicht wenn du die SymBox neu startest und den Tunnel inaktiv lässt.
paresy
Hi Paresy,
ich habe nach meinem Umzug von Win auf Raspi auch sporadisch das Problem:
bind: Die Adresse wird bereits verwendet (Code: -32603)
Tailscale oder auch Symbox habe ich nicht.
Gibt es denn eine Lösung außer Symcon neu zu starten? Mittlerweile (momentan) habe ich ja dann zwei externe Anbindungen (RazBerry und Homematic) bei denen ausschließlich ein Symcon Neustart hilft …
Ciao
HerbertF
Die Frage ist, ob du IPS_Execute oder exec/system/… in irgendwelchen Skripten nutzt? Denn wenn irgendein Progress gestartet wird, der beim Restart von Symcon immer noch aktiv ist, dann erbt dieser laut „fork“ unter Linux die FDs und dies produziert das Problem.
paresy
Hi Paresy,
Deine Antwort verstehe ich leider nicht. Ich nutze zwar IPS_Execute - siehe Screenshot, m.E. sind aber einige Scripts davon „Leichen“ und werden nicht mehr aufgerufen. Auf keinen Fall haben die etwas mit Homematic zu tun. Ich starte eigentlich AUCH NIEMALS nur Symcon sondern mache immer ein „sudo reboot“ - danach läuft alles wieder (sowohl RazBerry als auch Homematic).
Ciao
HerbertF
Die sind alle sehr Windows spezifisch. Ich vermute, da das Problem nur sporadisch auftritt, kannst du es nicht nachstellbar bekommen, oder?
paresy
Ich wüsste zumindest nicht wie …
Was ich natürlich tun könnte - bevor ich meinen Neustart ausführe … noch irgendeinen Befehl inkl. Ergebnis auszuführen (z.B.: sudo lsof > /home/pi/lsof.log)