Guten Morgen,
Ja, das ist mir bekannt. Falls das noch mal auftreten sollte, werde ich mal manuell versuchen, die HTTP-API via curl anzusteuern. Ich glaube nämlich nicht, dass das hier das Problem war und die Bridge mit der Abarbeitung nicht hinterher kam. Dann hätte ich auch andere Probleme mit der Bridge erwartet und es hätte nach dem Power-Off-Reset der Bridge wieder funktionieren müssen.
Das vermute ich auch. Das erklärt auch, warum nach genau 5 Sekunden immer der Status kam. Ich habe mir schon gedacht, dass das kein realer Status der Bridge ist, der dort ausgegeben wird.
Habe gerade mal einen schnellen Blick in den Code geworfen. Eigentlich kann das Script dann ja nur im curl-Teil hängen geblieben sein. Oder das IPS_SemaphoreLeave() wurde aus irgendeinem Grund nicht erfolgreich durchgeführt. Ich überlege gerade ob es Sinn macht:
a) Den Rückgabewert von IPS_SemaphoreLeave() mit auszuwerten und bei einem FALSE (wodurch auch immer das zustande kommen könnte) entsprechend zu reagieren.
b) Eine Umgehung für den Notfall zu bauen, die dafür sorgt, dass der Semaphor nach Ablauf einer gewissen Zeit in jedem Fall wieder aufgehoben wird, da das Modul sonst im Fehlerfall für die jeweilige Instanz bis zum nächsten Neustart des Dienstes tot ist. Denn mit der aktuellen Implementierung gibt es keinerlei Möglichkeit, ein einmal fehlgeschlagenes IPS_SemaphoreLeave() jemals wieder zu erreichen.
c) Den Timeout für den Semaphore in Abhängigkeit der Timeout-Property zu setzen. Das dürfte zwar nicht die Ursache für das Problem sein, würde aber bei einem hohen eingestellten Timeout (z.B. 10 Sekunden) dazu führen, dass ein zwischenzeitlich abgesetzter neuer Befehl in jedem Fall scheitert - vorausgesetzt die Bridge benötigt für ihre Antwort wirklich länger als die fixen 5 Sekunden.
Warum sich der IPS-Dienst während des Promles nicht beenden ließ, ist mir aktuell noch ein Rätsel. Dass ein Thread des Moduls komplett hängen geblieben ist, würde ich eigentlich ausschließen. Denn ich sehe im Monitoring keinen Thread, der länger als normal gelaufen wäre und ich habe relativ lange auf den Shutdown gewartet bis ich den Dienst am Ende gekillt habe. Das wird also irgendwas anderes gewesen sein. Wäre ganz hilfreich, wenn man im Nachgang noch über die Logs feststellen könnte, auf welche Scripts IPS beim Beenden (vergeblich) gewartet hat.
@paresy Kann man diese Info nicht irgendwie mit ins Log schreiben?
Also diese Loge-Einträge mit zusätzlichen Informationen anreichern, welche Skripte / Module aktuell noch laufen, auf die gewartet wird?
Warte auf Beendigung aller Skript-Threads...
Skripte können nicht gestartet, sobald Abschaltung eingeleitet wurde
Aktion konnte für Ereignis #123450 nicht ausgeführt werden: Skripte können nicht gestartet, sobald Abschaltung eingeleitet wurde
Weiß jemand, ob es Auswirkungen auf den Shutdown hat, wenn zwar kein Skript mehr läuft, aber noch irgendwo ein Semaphor gesetzt ist? Würde das ebenfalls das Herunterfahren des Dienstes verhindern?
Ich werde das mal weiter beobachten. Falls es noch mal auftritt, versuche ich noch weitere Daten zu sammeln, die bei der Ursachenfindung helfen könnten. Aber bisher war das wirklich die Ausnahme. War glaube ich erst das zweite Mal seit ich das Modul nutze, dass da was komplett hängen geblieben ist.
Gruß
Slummi
!