Wie gesagt:
OS Windows Server 2025
läuft viruell in Proxmox-Host auf PC-Hardware
Zwischen Fritzbox (Transit-Netz) und dem Proxmox-Server hängt eine OpnSense-Firewall (auf physischer Hardware)
Alle Komponenten (Symcon, Windows, Proxmox, Opnsense) werden regelmäßig gepatcht und sind aktuell.
Könnte DNS stören? Nutze einen Werbeblocking DNS. Symcon-Connect wird natürlich aufgelöst. Wenn ihr aber irgendwelche Tracker einsetzt, wird es schwierig, da wird DNS nicht aufgelöst.
Ich vermute auch, dass es am DNS kleben bleibt. Es ist definitiv die Anfrage nach live.symcon.de die am Ende versucht wird zu erreichen, um den Connect Dienst zu starten. Das spannende ist, dass scheinbar keines der definierten Timeouts greift. 
paresy
Bei mir auch Windows in Proxmox. Keine Veränderungen am Betriebssystem (ausser IPS und Firefox läuft auf dem Windows nichts) , keine Firewall-Veränderungen.
Ich habe Windows und IPS komplett neu installiert. Keine Besserung.
Connect ist bei mir deaktiviert.
Wenn ich den Dienst mit ‘taskkill’ beende und neu starte, läuft alles normal.
Wie sieht es bei den anderen aus?
@Sascha Läuft bei dir auch Proxmox als Host?
Das sieht ja nach einem guten Hinweis aus, mit dem wir weiter kommen, wenn es damit nachstellbar wird 
paresy
Auch wenn es nur eine negative Rückmeldung ist:
Habe auch PVE am laufen, allerdings eine Win 11 VM mit aktueller 9.0 Beta und bei mir startet der Dienst problemlos durch.
Connect Dienst ist auch aktiv.
Michael
Entschuldigt bitte die späte Rückmeldung 
Hier meine Daten zum System (Siehe auch Bild)
Hardware & Betriebssystem
Gerät: Mini-PC
Betriebssystem: Windows 11 Pro
Firewall: Windows 11 Onboard-Tool
Virenschutz: Windows 11 Onboard-Tool
Hausautomation: IP-Symcon
Infrarot-Steuerung: IR-Trans
Backup & Recovery: Acronis True Image
Netzwerk: Ubiquiti Controller (konfiguriert als Windows-Dienst)
USV-Software: NUT (Network UPS Tools)
Rolle: USV-Master
Funktion: Automatisierter Shutdown-Befehl für zwei Synology-NAS-Systeme bei Stromausfall.
Gerne kannst du auch mal per AnyDesk bei mir drauf schauen
3 Beiträge wurden in ein neues Thema verschoben: Ausfall bei der DENIC
Ich habe eine ziemlich ähnliche Konstellation, wie @Sascha (von Backup und IR mal abgesehen und die Hardware ist ein wenig anders).
Ich habe bisher zwar keine Probleme, dass IPS nicht startet, aber seit dem IPS-Update gestern sehe ich vermehrt diverse Verbindungsprobleme.
Mal ist ein Gerät aus IPS heraus nicht anpingbar (Device Monitor), dann reagiert das KNX-Gateway mal nicht (Timeout), dann sehe ich mehrfache Neuverbindung zum Connect-Dienst und DNS-Auflösungprobleme zu live.symcon.de und amazon.de (Alexa).
Ist vielleicht Zufall, aber ich sehe das erst seit dem Update auf die aktuellste Stable gestern. Ansonsten wurde das System nicht von mir angefasst. Ich starte das System gleich mal neu.
Also live.symcon.de wird bei mir natürlich zuverlässig aufgelöst. Schwierig wird es für Werbenetze wie doubleclick usw.
Ich bin Softwareentwickler, kenne aber natürlich die Symcon-Architektur nicht. Das der Connect-Versuch auf Symcon.de den Dienst in unendlich langes Warten schickt, ist aber nicht schön für den WAF. Ich verstehe aus komerziellen Gründen die Bedeutung des Connect-Dienstes für das Abo-Model. Mein Haus sollte aber auch laufen, wenn Netze zicken, egal ob DNS/… die Ursache sind. Kann man diese Verbindungsversuche nicht in einen separaten Thread kapseln? Dass würde zwar die Ursache nicht klären, aber Symcon würde wenigstens starten. Im Main-Thread während des Starts sollen meines Erachtens keine externen Verbindungen alles blockieren dürfen. Wie gesagt, nur Ideen - ich habe keine Ahnung wie das gebaut ist.
(Ich habe übrigens auch ein IR-Trans-Modul, das zur Bootzeit von Symcon meist nicht am Strom hängt!?)
wir haben wir alle Requests inkl. DNS Auflösung in cURL passende Timeouts gesetzt. D.h. auch ohne Internet sollte Symcon immer hoch kommen. (Ohne Subskription würde übrigens ein Fehler kommen und Symcon weiter starten. Hier klemmt etwas)
Die Frage ist aktuell, ob das Upgrade von cURL in der 9.0 was ausgelöst hat oder irgendein externer Einfluss sich hier verändert hat. Ein Update auf die allerneuste cURL Version (in der aktuellen Beta) hat bisher keine Verbesserung gebracht. Deswegen versuche ich das hier nachzustellen, um die Ursache besser zu verstehen, warum die Timeouts nicht greifen.
paresy
Also ich habe das System jetzt mal neu gestartet, aber die unterschiedlichen Konnektivitätsprobleme (KNX, Ping, Modbus etc.) treten immer noch auf. Ist jetzt nicht so, dass irgendwas gar nicht mehr funktioniert, aber zwischendurch gibt es immer unterschiedliche Fehler, die mit Verbindungen zu anderen Geräten zu tun haben.
Ist jetzt halt die Frage, ob das wirklich nur Zufall ist, dass das seit dem gestrigen Update passiert oder ob wirklich mit der IPS-Version was nicht stimmt. Von der vorherigen Stable habe ich dummerweise mal kein Backup gemacht.
@paresy Aber cURL dürfte doch nichts mit irgendwelchen Client-Sockets und Pings etc. zu tun haben, oder? Während ich schreibe gerade wieder Zeitüberschreitung bei KNX und Device Monitor sagt, einzelne Geräte seien nicht erreichbar. Läuft danach aber sofort wieder.
EDIT: Jetzt spinnt es komplett und alle paar Sekunden ist irgendeine Verbindung weg. Verrückt. Betrifft aber nur IPS. An anderen Stellen kann ich keine Probleme erkennen. Kann ich die vorherige Stable noch irgendwo laden? Wenn man mal einmal kein Backup macht…
5 Beiträge wurden in ein neues Thema verschoben: I/O abbrüche seit der 9.0
Sind wir hier schon weiter?
Heute ist der Dienst wieder nicht gestartet, nach Windows Update.
Liebe Grüße
Sascha
Hallo IP-Symcon Freunde,
nach einem nächtlichen Stromausfall habe ich folgende Situation nach Neustart des Rechners: ips_tray.exe ist gestartet, hängt aber in der Initialisierung fest. Der Dienst kann nicht gestartet werden und auch die Konsole kann nicht geöffnet werden. Die letzte Meldung im Logfile ist vom Archive Control und lautet „Generiere Zeitstempel für Zeitversatz-Änderung der eingestellten Zeitzone…“. In einem älteren Logfile habe ich gesehen, dass nach dieser Meldung die Aktualisierung der Aggregationsdaten der archivierten Variablen erfolgt.
- Ich dachte also an zerschossene Archivdateien durch das harte Ausschalten beim Stromausfall und habe daher den db-Ordner umbenannt. Kein Erfolg.
- Ich habe die settings.json durch eine aus dem Backup-Ordner ersetzt. Keine Erfolg.
Ich habe folgendes herausgefunden: Wenn man das „feststeckende“ ips_tray beendet, dann noch im Taskmanager den „IP-Symcon Service“ und dann die ips_tray.exe wieder startet, funktioniert alles ganz normal. Beim nächsten Neustart des Rechners geht die Sache aber wieder von vorne los.
Kann sich vielleicht jemand einen Reim darauf machen, was da durch das harte Ausschalten beim Stromausfall passiert ist? Es handelt sich um Symcon Professional 9.0 auf Windows 11.
@staman Ich habe die Beiträge mal hier her verschoben. Dann ist genau das hier das Problem, welches auch ein paar andere haben. Kannst du mir etwas mehr zu deinem System und Aufbau sagen? Welches OS? Ist es Virtualisiert?
Aktuell konnte ich es hier noch nicht nachstellen → Aktuell wirkt es so, als wenn cURL intern die DNS Anfrage nicht auflösen kann und dann in einem Deadlock steckt, bei dem nichtmal das gesetzte Timeout greift.
paresy
Mein Symcon-Server ist folgendermaßen aufgebaut:
