killing off a process tree

E

Erich Lin

Is there a command in ruby that when given the pid , it will terminate
all children processes of that pid including itself.

It seems that Process.kill(9, pid) only kills the parent and not the
children.


thanks
 
A

ara.t.howard

Is there a command in ruby that when given the pid , it will terminate
all children processes of that pid including itself.

It seems that Process.kill(9, pid) only kills the parent and not the
children.


harp:~ > ri Process.kill
----------------------------------------------------------- Process#kill
Process.kill(signal, pid, ...) => fixnum
------------------------------------------------------------------------
Sends the given signal to the specified process id(s), or to the
current process if _pid_ is zero. _signal_ may be an integer signal
number or a POSIX signal name (either with or without a +SIG+
prefix). If _signal_ is negative (or starts with a minus sign),
kills process groups instead of processes. Not all signals are
available on all platforms.

pid = fork do
Signal.trap("HUP") { puts "Ouch!"; exit }
# ... do some work ...
end
# ...
Process.kill("HUP", pid)
Process.wait

_produces:_

Ouch!

-a
 
M

Martin Lukasik

Is there a command in ruby that when given the pid , it will terminate
all children processes of that pid including itself.

It seems that Process.kill(9, pid) only kills the parent and not the
children.


[root@aster aster]# kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1
36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5
40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9
44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13
52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9
56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5
60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1
64) SIGRTMAX

You are killing process, so you will have "zombies" left sometimes.
Try sig 15 instead of using 9. Try sigquit (3) as well...

m.
 
F

Francis Cianfrocca

Erich said:
Is there a command in ruby that when given the pid , it will terminate
all children processes of that pid including itself.

It seems that Process.kill(9, pid) only kills the parent and not the
children.


thanks

I'll assume you're talking about Unix, even though when this question
comes up people are usually looking for something that works on Windows
too. The following is only meaningful on Unix.

There's no universally-valid assumption about the relationship between a
process and the processes that it forks (and the processes that the
children fork in turn). (In particular, processes invoked in the
foreground of a shell will have a relationship with their children and
grandchildren, but it's different with processes created by other
means.)

Try making your parent process a process-group leader. There are Ruby
APIs to support this- just make sure you call them in both the parent
and the child to avoid race conditions. In the child, set the process
group leader after the fork but before the exec. Now if you send a
signal to -n (where n is the pid of your parent process), then all of
the children will get the signal too.

Signal 9 is very unfriendly. Don't use it unless it's an emergency. Use
SIGINT or SIGTERM instead.
 
N

Name Name

I would like this to be portable on both linux and windows. Seemingly
you can only use 0-9 on windows, and none of them seems to kill a tree.
Some of them are even undefined signals. Can you do this process-group
leader thing on windows? Also , I would like to clarify my original
question. I meant taht I would call a parent process to open, which is
some program. And that program can POTENTIALLY open up other children
processes. The thing is I only have the pid of the parent, and when I
kill the parent, only the parent will die. Is there a way that I can
kill the parent and the children that it sprang (which I did not provide
the exec code for since they were provided by the parent itself that I
did not code).
 
E

Erich Lin

I would like this to be portable on both linux and windows. Seemingly
you can only use 0-9 on windows, and none of them seems to kill a tree.

Some of them are even undefined signals. Can you do this process-group

leader thing on windows? Also , I would like to clarify my original
question. I meant taht I would call a parent process to open, which is

some program. And that program can POTENTIALLY open up other children
processes. The thing is I only have the pid of the parent, and when I
kill the parent, only the parent will die. Is there a way that I can
kill the parent and the children that it sprang (which I did not
provide
the exec code for since they were provided by the parent itself that I
did not code).


Martin said:
Is there a command in ruby that when given the pid , it will terminate
all children processes of that pid including itself.

It seems that Process.kill(9, pid) only kills the parent and not the
children.


[root@aster aster]# kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1
36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5
40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9
44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13
52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9
56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5
60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1
64) SIGRTMAX

You are killing process, so you will have "zombies" left sometimes.
Try sig 15 instead of using 9. Try sigquit (3) as well...

m.
 
A

ara.t.howard

I would like this to be portable on both linux and windows. Seemingly
you can only use 0-9 on windows, and none of them seems to kill a tree.
Some of them are even undefined signals. Can you do this process-group
leader thing on windows? Also , I would like to clarify my original
question. I meant taht I would call a parent process to open, which is
some program. And that program can POTENTIALLY open up other children
processes. The thing is I only have the pid of the parent, and when I
kill the parent, only the parent will die. Is there a way that I can
kill the parent and the children that it sprang (which I did not provide
the exec code for since they were provided by the parent itself that I
did not code).

no. you can't even do it reliably on unix. a process can spawn a child which
become the child of init - eg it leaves the group.

maybe you should carefully outline what you are actually trying to do and see
what people come up with.

btw. - what's with spamming the list twice with your replies?

regards.

-a
 
D

Douglas McNaught

Erich Lin said:
I meant taht I would call a parent process to open, which is some
program. And that program can POTENTIALLY open up other children
processes. The thing is I only have the pid of the parent, and when
I kill the parent, only the parent will die. Is there a way that I
can kill the parent and the children that it sprang (which I did not
provide the exec code for since they were provided by the parent
itself that I did not code).

I don't think you can do this in the general case on Unix unless you
use ptrace(), which you really don't want to do. A process can only
know its immediate children. If you call setsid() in the child after
the fork(), and if the program you exec() doesn't do any
session-management calls (setsid(), setpgrp()) itself, then it will
probably work to call 'kill(-N, SIGTERM)' where N is the PID of your
child process (which is the parent of the other processes). If the
program you're calling does setsid() or setpgrp() on its own, you will
probably lose.

This session and process group stuff will bend your brain--it's not
simple at all. I have no idea whether you can do what you're looking
for on Windows, though you might be able to using the POSIX
extensions.

-Doug
 
D

Daniel Berger

Douglas said:
=20
I don't think you can do this in the general case on Unix unless you
use ptrace(), which you really don't want to do. A process can only
know its immediate children. If you call setsid() in the child after
the fork(), and if the program you exec() doesn't do any
session-management calls (setsid(), setpgrp()) itself, then it will
probably work to call 'kill(-N, SIGTERM)' where N is the PID of your
child process (which is the parent of the other processes). If the
program you're calling does setsid() or setpgrp() on its own, you will
probably lose.
=20
This session and process group stuff will bend your brain--it's not
simple at all. I have no idea whether you can do what you're looking
for on Windows, though you might be able to using the POSIX
extensions.
=20
-Doug
=20

Note that there is Process.sigsend if you have the proc-wait3 package:

require 'proc/wait3'

Process.sigsend(Process::p_PGID, gid, 'TERM')

This will not work on MS Windows, however. For Windows you'll have to =
use=20
sys-proctable and manually check for the ppid member value.

Regards,

Dan



This communication is the property of Qwest and may contain confidential =
or
privileged information. Unauthorized use of this communication is =
strictly=20
prohibited and may be unlawful. If you have received this communication =

in error, please immediately notify the sender by reply e-mail and =
destroy=20
all copies of the communication and any attachments.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top