Christian, ich hätte da noch mal eine Frage zum Beenden von EDOMI und wie sich ein EXEC Script dann geordnet beendet.
Ich habe 2 EXEC LBS Skripte, welche per default in einem blockierenden Status sind und erst dann fortgesetzt werden, wenn über eine message queue eine Nachricht ankommt.
Das Problem mit der Datenbank Connection war ja einfach zu lösen, indem man nach Empfang einer Nachricht ein sql_connect() macht. Funktioniert super.
Ein anderes Problem ist nun, dass ich die message queue beim Beenden von EDOMI nicht ordnungsmäß löschen kann, da der EXEC Prozess ja im blockierten Modus ist, wenn keine Nachricht ankommt. Daher greift das while getSysInfo()>=1 nicht, sondern EDOMI beendet den Prozess irgendwann hart.
Gibt es eine Lösung, wie ich im LBS Teil (EDOMI Logikschleife) mitbekommen kann, dass EDOMI gerade beendet wird? z.B. ein System-KO "System Shutdown". Das könnte ich auf einen Eingang des LBS legen und dann eine Message "Shutdown" an meinen EXEC Prozess senden. Dieser würde dann aufwachen, die while Schleife verlassen und die message queue ordnungsgemäß löschen.
Macht ein solchen System-KO Sinn?
Es müsste natürlich kurz vorher gesetzt werden, bevor EDOMI dann beendet wird. Ich denke es funktioniert derzeit ähnlich mit getSysInfo(). Und es müsste dann zeitlich noch gewährleistet sein, dass der LBS noch mal durchlaufen kann, um das Shutdown Signal an das EXEC Skript zu senden.
Ohne eine solche Funktion, sammeln sich mit der Zeit (bis zum nächsten Reboot) viele leere Message Queues an.
Aktives Warten im EXEC wäre natürlich eine Alternative, die mehr Ressourcen verbraucht, d.h. kein blockierendes Warten, sondern ständiges Durchlaufen der While Schleife mit einem usleep() am Ende.
Außerdem wäre interessant zu wissen, wie EDOMI die EXEC Prozesse beendet? Wird zuerst ein SIGTERM gesendet und danach ggf. ein SIGKILL? Ggf. wäre dann auch eine Lösung im EXEC Skript einen Signal-Handler zu installieren, welcher das TERM Signal abfängt, die Message Queue löscht und sich dann beendet. SIGKILL kann man m.W. nicht abfangen.
Wäre interessiert an Deiner Sicht? Vielleicht gibt es ja auch andere Ideen...
Ich habe 2 EXEC LBS Skripte, welche per default in einem blockierenden Status sind und erst dann fortgesetzt werden, wenn über eine message queue eine Nachricht ankommt.
Das Problem mit der Datenbank Connection war ja einfach zu lösen, indem man nach Empfang einer Nachricht ein sql_connect() macht. Funktioniert super.
Ein anderes Problem ist nun, dass ich die message queue beim Beenden von EDOMI nicht ordnungsmäß löschen kann, da der EXEC Prozess ja im blockierten Modus ist, wenn keine Nachricht ankommt. Daher greift das while getSysInfo()>=1 nicht, sondern EDOMI beendet den Prozess irgendwann hart.
Gibt es eine Lösung, wie ich im LBS Teil (EDOMI Logikschleife) mitbekommen kann, dass EDOMI gerade beendet wird? z.B. ein System-KO "System Shutdown". Das könnte ich auf einen Eingang des LBS legen und dann eine Message "Shutdown" an meinen EXEC Prozess senden. Dieser würde dann aufwachen, die while Schleife verlassen und die message queue ordnungsgemäß löschen.
Macht ein solchen System-KO Sinn?
Es müsste natürlich kurz vorher gesetzt werden, bevor EDOMI dann beendet wird. Ich denke es funktioniert derzeit ähnlich mit getSysInfo(). Und es müsste dann zeitlich noch gewährleistet sein, dass der LBS noch mal durchlaufen kann, um das Shutdown Signal an das EXEC Skript zu senden.
Ohne eine solche Funktion, sammeln sich mit der Zeit (bis zum nächsten Reboot) viele leere Message Queues an.
Aktives Warten im EXEC wäre natürlich eine Alternative, die mehr Ressourcen verbraucht, d.h. kein blockierendes Warten, sondern ständiges Durchlaufen der While Schleife mit einem usleep() am Ende.
Außerdem wäre interessant zu wissen, wie EDOMI die EXEC Prozesse beendet? Wird zuerst ein SIGTERM gesendet und danach ggf. ein SIGKILL? Ggf. wäre dann auch eine Lösung im EXEC Skript einen Signal-Handler zu installieren, welcher das TERM Signal abfängt, die Message Queue löscht und sich dann beendet. SIGKILL kann man m.W. nicht abfangen.
Wäre interessiert an Deiner Sicht? Vielleicht gibt es ja auch andere Ideen...
Allerdings bleiben Deinem LBS nur ca. 3 Sekunden, um entsprechend zu reagieren - denn dann wird die Logikengine quasi beendet und der LBS-Teil wird nicht mehr verarbeitet.
Kommentar