Arch Linux

Programmende auffangen

Ovion

Hi,
ich würde gerne eine Prozesskillroutine schreiben, die erst mit kill auf den Prozess losgeht und wenn dieser sich weigert, zu sterben, mit kill -9.

pid=zu-killende-programm-pid
kill $pid
kill -9 $pid
if [[ $? == 0 ]] then
#Wenn exit-code von "kill -9" null (kill -9 ging, weil $pid noch am Leben)
	echo $proc killed
else
	echo $proc terminated
fi

Das Problem, was ich jetzt zu haben glaube, ist, dass kill -9 losrennt, bevor das Programm, dass mit kill terminiert werden soll, mit dem kill-bedingten Aufräumen fertig ist. Folge: faktisch wird jedes Programm bei diesem Code mittels kill -9 abgeschossen wird, was eigentlich nicht der Plan ist. Ich könnte jetzt ein "sleep" zwischen die beiden kills schieben, damit könnte ich den Prozessen aber nur einen definierten Zeitraum zum Aufräumen geben, ich würde am liebsten irgendetwas haben, was darauf wartet, dass der Prozess mit dem aufräumen fertig ist oder nicht.
Allerdings vermute ich, da kill nur Signale sendet, dass ich einfach keine Möglichkeit habe, zu unterscheiden, ob der Prozess gerade aufräumt oder blöd in der Gegend herumsteht, sollte ich hiermit Recht haben, würde ich gerne Empfehlungen haben, wie lange ich Prozessen Zeit zum Aufräumen geben sollte, um aufräumende Prozesse in Ruhe zu lassen und hängende zu killen. Ich bin mit solchen Zeiträumen so überhaupt nicht vertraut.
Alternativ ist ein gänzlich anderer Lösungsansatz für das Problem ebenfalls gerne gesehen.

Besten Dank schonmal!

[gelöscht]

vielleicht so (bash):

# terminate:
kill pid

# wait up to 5 secs:
for (( c=0; c<5; c++ )); do
  sleep 1s;
  ps -C program || exit 0
done

# process always exists, kill it:
kill -9 pid
exit 1

Dirk

kill ${PID} && kill -9 ${PID}

hydro

So einfach scheint es nicht zu sein, kill erfährt nur, ob das Signal angekommen ist, nicht ob der Prozess sich beenden wird.
http://www.unix.com/302480742-post5.html

Ovion

hydro schriebSo einfach scheint es nicht zu sein, kill erfährt nur, ob das Signal angekommen ist, nicht ob der Prozess sich beenden wird.

Das ist eben genau das Problem.

@Dirk
Dein Code macht genau dasselbe wie meiner oben (abgesehen vom Output), wenn mich nicht alles täuscht, oder irre ich da?

@crashmaster
Danke, aber dann lieber eine feste Zeit. Das Ganze liegt in einem etwas komplexeren Codeblock, eine for-Schleife einzubauen wäre overkill und der Lesbarkeit nicht zuträglich.
Sind die 5s aus der Luft gegriffen oder gibt es tatsächlich Prozesse, die so lange zum aufräumen brauchen (wenn ich jetzt mal von riesigen Programmen absehe, die zig Netzwerkverbindungen und was nicht noch alles zumachen müssen)?

Dirk

Ich dachte bisher ja immer, dass kill zurückmeldet, was das Programm macht, bzw. dass es fertig ist, oder eben nicht 🙂 Eigentlich hab ich kill bisher „regulär“ noch nie benötigt, sondern die Prozesse, von denen ich wusste/weiß, dass sie hängen, immer gleich ge-kill-neunt 🙂

[gelöscht]

Ovion schrieb @crashmaster
Danke, aber dann lieber eine feste Zeit. Das Ganze liegt in einem etwas komplexeren Codeblock, eine for-Schleife einzubauen wäre overkill und der Lesbarkeit nicht zuträglich.

Es muss ja keine Schleife sein.

Ovion schrieb Sind die 5s aus der Luft gegriffen oder gibt es tatsächlich Prozesse, die so lange zum aufräumen brauchen (wenn ich jetzt mal von riesigen Programmen absehe, die zig Netzwerkverbindungen und was nicht noch alles zumachen müssen)?

Die 5 sek. sind nur als Beispiel gedacht und im Normalfall nicht weiter tragisch:
Die Schleife wird ja spätestens 1 sec nachdem der Prozess aus der Prozessliste verschwunden ist, abgebrochen.
Was ein Prozess nach Empfang eines TERM Signals noch zu tun hat und wielange das dauert, mußt Du sonst selbst abschätzen. Deshalb hat die Schleife mit der 1-sekündigen Abbruchbedingung schon einen großen Vorteil.

Ein "kill -9" sollte bei gut programmierter Software nie gebraucht werden. 😉

Ovion

crashmaster schriebEin "kill -9" sollte bei gut programmierter Software nie gebraucht werden. 😉

Sollte, mein Lieber, sollte...

Die Schleife hat in der Tat den Vorteil des zeitlich rausspringens, aber kostet mich halt auch zweimal drei Zeilen Code mehr und die Funktion ist schon relativ lang, daher hadere ich noch. Aber ich behalt's im Hinterkopf!