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.
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.
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!
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
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
man könnte die /etc/init.d/symcon auch einfach anpassen.
aus
stop)
PID=$(pidof symcon)
if [ -z $PID ]; then
echo "IP-Symcon is not running"
else
kill -15 $PID
while ps -p $PID > /dev/null; do sleep 1; done;
echo "IP-Symcon stopped"
fi
;;
wird dann
PID=$(pidof symcon)
if [ -z $PID ]; then
echo "IP-Symcon is not running"
else
count=0
kill -15 $PID
while ps -p $PID > /dev/null
do
sleep 1
count=$(expr $count + 1)
while [ $count -gt 29 ]
do
kill -9 $PID
count=0
done
done
echo "IP-Symcon stopped"
fi
es wird 30 sek gewartet und wenn der Service immer noch da ist, wird mittels kill -9 beendet.