lothar.behrens@lollisoft.de schrieb:

Am 31 Jan 2006 um 9:21 hat Bernard.Bramlage@kisters.de geschrieben:

Vielleicht hilfts:

## install trap for automatic deletion of TMPFILE and MSGFILE at ## SIGEXIT (0) see 'man bash' and all other signals. The trap for ## SIGKILL (9) is ignored though, of course. See 'help trap'. trap "rm -f \"$TMPFILE\"; rm -f \"$MSGFILE\";" `seq 0 63`

Lothar

...

Hallo, ich habe folgende Situation. Ein C++ Programm ruft mit execve ein Bash Skript auf und wartet mit waitpid() auf die normale Beendigung. Wenn die Ausführung des Skriptes zu lange dauert, soll es mit kill(pid, SIGKILL) beendet werden. Das Skrpt selber ruft wieder ein C++Programm auf. Jetzt ensteht folgende Situation. Nach dem kill() geht das Skript in den Status defunct und das vom Skript aufgerufene Programm läuft normal weiter. Hierzu jetzt 2 Fragen: Wie kann ich erreichen, dass auch das vom Skript aufgerufene Programm beendet wird, also das kill() quasi weitergegebe wird? Wir verhindere ich, dass das Skript in defunct geht? Ich muss wahrscheinlich nach kill nochmal waitpid() aufrufen, möcht hier aber nicht ewig warten müssen.

Vielen Dank im voraus für eure Hilfe.

Gruß Bernard

du kannst doch die pid des gestarteten programms ermitteln ($# glaub ich) versuch doch die an dein erstes programm zu übergeben und dann ggf kill(pid, ...); danach sollte sich das skript ja automatisch beenden, ansonsten musst du das skript noch anpassen greatz Johannes -- Es gibt 10 Arten von Menschen auf dieser Welt, die einen verstehen das Binärsystem und die anderen verstehen es nicht.

Am 2 Feb 2006 um 16:41 hat Bernard.Bramlage@kisters.de geschrieben: Ich kenne noch pstree. Damit kann man sehen, welche Prozesse von wem gestartet wurden. Also muss es möglich sein, seine 'Kinder' zu 'killen' - sorry :-) Dann kenne ich noch killproc 'name'. Ich glaube, das löst den Namen zur PID auf und führt kill 'PID' aus. Vielleich selbst nur ein script. Lothar

hallo, die Vorschlag über trap das signal abzufangen ist glaube ich der richtige Weg. Als Aktion müßte da ein kill des im Skript aufgerufenen Propgramms stehen. Das Von dem Programm nicht die PID habe und auch nicht weiß wie ich sie bekomme ohne das Programm in den Hintergrund zu schicken, bin ich nicht weitergekommen. Ich habe jetzt den Aufruf des Programm direkt ohne Skript gemacht und hinter dem kill() noch ein waitpid() eingebaut und es funktioniert. Da ich aber sonst auch mit Skripten arbeite bin ich weiterhin an eine Lösung interessiert. Insbesondere stellt sich mir die Frage, gibt es eine Möglichkeit ein signal an child prozesse zu schicken, ohne deren PID zu kennnen?

Hier das Skript: #!/bin/bash # file: startx.sh

export SODA="/usr/soda" export PATH="/usr/soda/bin:$PATH" export LD_LIBRARY_PATH="/usr/soda/lib" xscall "$@"

Wenn dies Skript gekillt wird, läuft das Programm xscall weiter. Schön wäre es wenn nach dem Abfangen eines signals, dies an das Programm xscall weiergegeben werden könnte.

Gruß Bernard

Johanns Schneider wrote on 02.02.2006 13:57:05:

...

lothar.behrens@lollisoft.de schrieb:

...

Am 31 Jan 2006 um 9:21 hat Bernard.Bramlage@kisters.de geschrieben:

Vielleicht hilfts:

## install trap for automatic deletion of TMPFILE and MSGFILE at ## SIGEXIT (0) see 'man bash' and all other signals. The trap for ## SIGKILL (9) is ignored though, of course. See 'help trap'. trap "rm -f \"$TMPFILE\"; rm -f \"$MSGFILE\";" `seq 0 63`

Lothar

...

Hallo, ich habe folgende Situation. Ein C++ Programm ruft mit execve ein Bash Skript auf und wartet mit waitpid() auf die normale Beendigung. Wenn

die

...

Ausführung des Skriptes zu lange dauert, soll es mit kill(pid, SIGKILL) beendet werden. Das Skrpt selber ruft wieder ein C++Programm auf. Jetzt ensteht folgende Situation. Nach dem kill() geht das Skript in den Status defunct und das vom Skript aufgerufene Programm läuft normal weiter. Hierzu jetzt 2 Fragen: Wie kann ich erreichen, dass auch das vom Skript aufgerufene Programm beendet wird, also das kill() quasi weitergegebe wird? Wir verhindere ich, dass das Skript in defunct geht? Ich muss wahrscheinlich nach kill nochmal waitpid() aufrufen, möcht hier aber nicht ewig warten müssen.

Vielen Dank im voraus für eure Hilfe.

Gruß Bernard

du kannst doch die pid des gestarteten programms ermitteln ($# glaub ich) versuch doch die an dein erstes programm zu übergeben und dann ggf kill(pid, ...); danach sollte sich das skript ja automatisch beenden, ansonsten musst du das skript noch anpassen

greatz Johannes

-- Es gibt 10 Arten von Menschen auf dieser Welt, die einen verstehen das Binärsystem und die anderen verstehen es nicht.

-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com

-- Lothar Behrens | Rapid Prototyping ... Rosmarinstr 3 | 40235 Düsseldorf | www.lollisoft.de

Hallo Bernard! Bernard.Bramlage@kisters.de schrieb:

hallo, die Vorschlag über trap das signal abzufangen ist glaube ich der richtige Weg. Als Aktion müßte da ein kill des im Skript aufgerufenen Propgramms stehen. Das Von dem Programm nicht die PID habe und auch nicht weiß wie ich sie bekomme ohne das Programm in den Hintergrund zu schicken, bin ich nicht weitergekommen. Ich habe jetzt den Aufruf des Programm direkt ohne Skript gemacht und hinter dem kill() noch ein waitpid() eingebaut und es funktioniert. Da ich aber sonst auch mit Skripten arbeite bin ich weiterhin an eine Lösung interessiert. Insbesondere stellt sich mir die Frage, gibt es eine Möglichkeit ein signal an child prozesse zu schicken, ohne deren PID zu kennnen?

Mit der Funktion kill() unter Unix kann man ein Signal auch an mehrere Prozesse schicken, die derselben Prozeßgruppe angehören wie der Aufrufer der kill()-Funktion. Dafür übergibt man der Funktion als pid des Prozesses, der das Signal empfangen soll, einfach eine 0. Alternativ kann man die Funktion killpg() verwenden. Dies kann man nutzen, um einen Prozeß und alle seine Kindprozesse zu terminieren. Man muß nur dafür sorgen, daß dieser Prozeß und seine Kindprozesse in einer eigenen Prozeßgruppe sind. Dies erreicht man, wenn der Elternprozeß eine neue Prozeßgruppe definiert, wofür er die Funktion setpgid() verwenden kann. Meines Erachtens müßtest Du also in etwa folgende Vorgehensweise implementieren: 1. Das C++-Programm definiert mit setpgid() eine neue Prozeßgruppe. 2. Das C++-Programm ruft fork() und exec() auf, um das Bash-Script zu starten. Dabei erbt das Bash-Script die neue Prozeßgruppennummer. 3. Das Bash-Script startet weitere Prozesse, die dank fork() auch die neue Prozeßgruppennummer erben (sollten). 4. Das C++-Programm ruft kill() auf, wobei es als PID 0 angibt. Dabei werden nun alle Prozesse mit der neuen Prozeßgruppennummer das gesendete Signal erhalten - in Deinem Fall also SIGKILL. Das sind aufgrund der obigen Konstruktion alle Kindprozesse und deren Kindprozesse, sofern sie nicht wieder eigene Prozeßgruppen erzeugt haben, was ich in der von Dir beschriebenen Konstruktion aber für sehr unwahrscheinlich halte. Ausprobiert habe ich das jetzt nicht, aber nach meinem Verständnis müßte es so funktionieren. Schau aber auf jeden Fall nochmal in die Man-Pages der genannten Funktionen. Grüße, Alex. -- "Mit dem ersten Glied ist die Kette geschmiedet. Wenn die erste Rede zensiert, der erste Gedanke verboten, die erste Freiheit verweigert wird, sind wir alle unwiderruflich gefesselt." (Cpt. Picard, ST:TNG) --------------------------------------------------------------------- Alexander Glintschert Das andere Berlin Email: alex@glintschert.de Email: info@anderes-berlin.de WWW: http://www.glintschert.de WWW: http://www.anderes-berlin.de Das andere Berlin - Was nicht jeder Reiseführer weiß - und mancher Berliner auch nicht.