Hi Kris,
Oha und das tut mir leid 
… wenn du Infos brauchst, sag Bescheid.
Gruß Michael
Ich bin auch einen Schritt weiter und denke den Übeltäter gefunden zu haben, weil nach einem Neustart von IP-S passiert das:
14.03.2023 12:26:39 | 36258 | MESSAGE | DeconzGateway | Erstelle...
14.03.2023 12:26:39 | 36258 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: Create
14.03.2023 12:26:39 | 36258 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: Create ~ Dauer: 0 ms
14.03.2023 12:26:39 | 36258 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ApplyChanges
und dann erst mal längere Zeit ( ca. 15 min ) nichts mehr, das System hängt im Startprozess, die WebGUI meldet das auch.
Nach den 15 min läuft der Start und kurz danach ist auch die WebGUI verfügbar.
Da ich das DeconzGateway aber eh entsorgen will, hab ich das Modul über den Modulstore deinstalliert, sämtlichen damit verknüpften Lampen gelöscht und alle Objekte, Instanzen usw. die ich gefunden habe, auch gelöscht. Es sollte davon nichts mehr übrig sein.
Anschliessend wieder. restart IP-S
( Fortsetzung folgt, da hängt der derzeit nämlich )
Fortsetzung: Restart von IP-S war nicht erfolgreich, IP-S war offline nach einem „systemclt stop symcon“.
Maschine komplett rebootet - Start von IP-S. war sehr schnell erledigt, keine Hänger im Log zu sehen.
Jetzt stellt sich die große Frage(n):
- warum brauch das DeconzModul solange zu starten ?
- einer meiner RasPi mit dem Raspi II Modul ist derzeit nicht erreichbar ( darum fliegen die auch raus, die Teile nerven mich ständig mit Ausfällen ), da würde ich aber erwarten, das nach max. 2 Min das Modul bei starten abbricht mit Timeout
- oder hat das Modul selber ein Problem - evtl. nach einem Update von Modul selber, von IP-S oder vom Ubuntu-OS
Fragen über Fragen.
Ich hab nun meine Backups wieder auf Offline-Backup umgestellt und auch die System-Updates mit Reboot aktiviert - spätestens dann zeigt sich, ob der Fehler weg.
probiere mal in der Shell vom Proxmox
pct stop <vmid>
auszuführen. Müsste klappen.
Ich habe ja auch schon vor längerer Zeit von dem Problem berichtet, manchmal läuft das stoppen von IPS durch manchmal nicht. Dann muss es entweder an mehreren Modulen liegen oder an IPS selber. Ich selber nutze kein PontoBase und kein Deconz Modul.
Ich hab den immer über Proxmox rebooten müssen, ging anders garnicht mehr
Nach dem ich das PHP-Modul rausgeworfen habe, funktionierte nun aber auch der reboot direkt auf dem OS wieder normal und innerhalb weniger Sekunden - wie gewohnt.
Ich vermute auch, das es hier eher ein IPS-Problem ist und nicht bei den Modulen zu suchen ist - evtl. die Kommunikationsschnittstelle dazwischen, aber dafür bin ich zuwenig Softwareentwickler.
Wenn du mal in dein /var/log/symcon/logfile.log schaust bei einem Neustart ob der dort auch an einer Stelle hängen bleibt.
Das war bei mir eindeutig.
Zudem sag man in den PHP Informationen einige rote Einträge, wo kurzzeit immer mal wieder das Script angezeigt wurde, das Meldungsfenster war nicht sonderlich hilfreich.
Ich hab das Problem auf meinem Test-Server ja nicht und der ist komplett gleich aufgesetzt vom OS her, hat die selbe IP-S version, nur sind da erheblich weniger Geräte, Instanzen usw. installiert, weil ich den nur zum testen von irgendwelchen Einstellungen usw. nutze.
Noch ein kleines Update:
- PHP Liste ist sauber, keine hängenden Jobs
- Meldungsliste ist sauber, nichts rotes mehr zu sehen
- reboot des Containers geht fix innerhalb von wenigen Sekunden, so wie es sein soll.
Bleibt die große Frage im Raum:
- was ist das für ein Problem, das scheinbar ja mehrere Module haben.
Hi…
Ich hatte (siehe hier) ein ähnliches Problem.
Eine Neuinstallation mit anschließendem Einspielen des Backups hat das Problem bei mir behoben.
Grund für das Problem konnte ich bis zum Schluss nicht rausfinden…
Viele Grüße
Jochen
es gibt schlichtweg kein Timeout - welches vom System vorgegeben ist - mehr. Früher war ein Timelimit von, lass mich nicht lügen, 60 sek. Das ist aufgehoben.
Dafür ist der Modulbauer verantwortlich ein Timeout festzulegen oder sorge zu tragen, das ein Modul kein Zombie wird
Hoffentlich wissen die das auch. 
Hi,
Learning by doing. Ich bin bei meinem modul auch nicht davon ausgegangen das es zu einem problem wird 
Wäre es vielleicht denkbar, ein systemtimeout von, sagen wir mal 6 stunden einzuführen?
Dann kann es zwar immer noch probleme beim reboot geben, aber wenigstens laufen nicht module amok…
Dazu noch einen neuen systeminstanzcode ähnlich zu 101, 102 etc um zu signalisieren, das die instanz zwar aktiv ist aber ein systemtimeout griff und deswegen ein thread gekillt wurde.
Optional dann ein gerätetyp namens listener o.ä. der aus dem timeout rausgenommen wird. Sozusagen für die profis 
Viele grüße
Nein. Siehe Migration 6.0
Neu: max_execution_time in PHP auf 0 gesetzt, weil es Ursache für viele Abstürze war.
Quelle:
V5.5->V6.0 (Q3/2021) — IP-Symcon :: Automatisierungssoftware
Das ging, wie erst letztes schon geschrieben, noch nie.
Wenn er hängt war es das.
Michael
Hi,
ok, dann hatte ich das falsch in Erinnerung. Schade.
Viele Grüße
Moin Moin,
Ich will mich da nicht einmischen, aber es muss/sollte doch möglich sein, wenn man auf Systemebene einen „Service Stop“ bewusst macht, das dann alles! dicht gemacht wird und dieses auch ins Log schreibt. Ich wäre ohne Kris und Integry Check nie drauf gekommen.
Gruß Michael
Bin ich voll bei dir.
Ich würde einem Entwickler bei uns in der Firma sein System um die Ohren hauen, wenn wir nicht automatisiere Updates und Reboots machen können - das ist Mindestanforderung an alle System bei uns.
Wen das nichts funktioniert, können dir ihre Windows/Linux-Updates auf dem Systemen nämlich dann selber machen und das heisst dann abends oder am Wochenende - deren Problem dann.
Ich update alle meine Linux-System automatisch, mit sowas halte ich mich nicht auf, das muss laufen - und genau darüber bin ich ja bei IP-S gestolpert, weil es plötzlich nicht mehr ging und morgens mein System offline war, die Heizung im Bad kalt, Handys nicht geladen usw.
Anstatt hier über Symptome zu schreiben (Shutdown Problem), sollte man die Ursache (langlaufende und hängende Threads) beseitigen.
Und das sind einfach schlechte cURL Abfragen in Scripten und Modulen.
Per default stehen fast alle Timeouts auf unbestimmt.
Gerade der Connect-Timeout mit seinen 5 Minuten kann, wenn man alle x Sekunden was abfragt, alles blockieren.
libcurl lists the following connection timeout specific settings:
- CURLOPT_FTP_RESPONSE_TIMEOUT: No default (indefinite)
- CURLOPT_TIMEOUT: No default (indefinite)
- CURLOPT_TIMEOUT_MS: No default (indefinite)
- CURLOPT_CONNECTTIMEOUT: Defaults to 300 seconds
- CURLOPT_CONNECTTIMEOUT_MS: No default
- CURLOPT_ACCEPTTIMEOUT_MS: Defaults to 60000 ms
The PHP source code does not override any of the above default settings
Andererseits steht hier das es kein Connect-Timeout gibt 
Michael
1 „Gefällt mir“
Hi,
Sorry Nall-chan, aber ein vom System ausgeführtes stoppen oder neustarten des Dienstes hat IMMER zu funktionieren. Und nicht erst durch harten reboot.
Dafür gibt es die entsprechendes sigkills, auch wenn das nur die letzte lösung sein sollte.
Es kann einfach nicht sein, das eine so plumpe Abfrage einem das System so um die ohren haut. Zumal der ganze host neugestartet werden muss.
Viele grüsse
1 „Gefällt mir“
Will mich bestimmt nicht einmischen , aber mit einem kill -9 hab ich ips noch immer zum beenden gebracht. Reboot war deshalb noch nie in über 10 Jahren notwendig!
Ist auch meine wahl der Dinge, wenn was schief läuft 
Kommt aber seit einiger Zeit nicht mehr zum tragen. 
1 „Gefällt mir“
Okay, reden wir über Symptome…
Hast du geschaut ob auch wirklich ein SIGKILL gesendet wird?
Das wäre ein abschießen des Prozesses.
Aber ein normale beenden des Dienstes ist ein SIGTERM. Und dann hängt der Dienst ja.
Wobei eigentlich schon vorher; die PHP Threads hingen ja schon vorher.
Und es ist nicht nur Linux. Auch unter Windows habe ich gerne ein hängendes IPS beim beenden vom Dienst. Ist aber mein Module-Dev System, da geht gerne mal was kaputt. Auch hier hilft immer ein abschießen vom Task.
Auch beim Windows Updates und rebots killt Windows hart den Dienst, wenn er zu lange braucht.
Beim Linux weiß ich das nicht, schätze mal aber identisch.
Wenn jetzt eigene Jobs genutzt werden um den Dienst zu beenden, muss man das vermutlich selber umsetzen (also prüfen ob der sigterm erfolgreich war) und nach dem Timeout den Prozess killen.
Möchte ich einen Aufgaben-Prozess (Backup, Updates etc) automatisieren, muss ich mit Fehlern rechnen und diese in meinem Prozess einbeziehen. Perfekte, fehlerfreie Software gibt es nicht. Sonst würden auch die PHP-Module perfekt und fehlerfrei sein und nicht die PHP-Threads mit curl zum erliegen bringen
Michael
Huhu,
Ich habe die probleme (aktuell) nicht, mein modul hat das problem bei @tissenm ausgelöst und beim @Tuxtom007 war es das deconz modul.
Ich kann mich nur an deren aussagen orientieren das ein systemctl nicht geholfen hat und selbst das beenden des containers keine abhilfe gebracht hat.
Aber ja, ein reboot des hosts killt alles was bei x nicht beendet ist.
Ein killall symcon oder kill -9 $(pidof symcon) muss es hart beenden.
Hey Jungs,
ich mag mich auch nicht einmischen 
, aber ich schaue trotzdem mal, ob ich nach Timeout X Minuten beim Beenden IP-Symcon lieber abstürzen lassen kann, anstatt dass es ewig festhängt. Sicherlich beides nicht optimal - ich verstehe aber, dass ein komplett feststeckendes System doofer ist, als ein kontrollierter Absturz. Bei den internen Timern machen bereits sowas ähnliches - warum nicht auch bei den PHP Threads.
paresy
2 „Gefällt mir“