Lets kill this thread, and for those of us that needs some education about the
effects of kill -1.
<snipped from man kill>
pid ...
Specify the list of processes that kill should sig-
nal. Each pid can be one of four things. A pro-
cess name in which case processes called that will
be signaled. n where n is larger than 0. The pro-
cess with pid n will be signaled. -1 in which case
all processes from MAX_INT to 2 will be signaled,
as allowed by the issuing user. -n where n is
larger than 1, in which case processes in process
group n are signaled. IFF a negative argument is
given the signal must be specified first, otherwise
it will be taken as the signal to send.
--And more about the behavior of XFree in the above situation:
Linus Torvalds wrote:
> In article <m0zcWvU-0007U9C@the-village.bc.nu>, > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > >> I did put in one sleep and tested on my macine: > >> ./fork 100 - 1 sec > >> ./fork 200 - 2 sec > >> ./fork 300 - 2 sec > >> ./fork 400 - 3 sec > >> ./fork 500 *** My machine totally hangs. > >> > >> Please Alan, Can you explain this or is this some bug in the kernel?? > > > >Looks like a 2.1.127 bug - 2.0.36pre16 didnt fall over, 2.1.127 did > > Umm, 2.1.127 doesn't fall over either. But if you run this as root (and > judging by the number of processes you had, you did), then the program > is buggy enough that you will essentially kill the system.. > > Look at what you do: you do a large number of "fork()" calls, and you > save the pid's off into an array if they are non-zero. IN PATICULAR: > when you don't have any more processes left, and fork() returns -1, you > will save that off as a pid without noticing (the test for the return > value of fork() is "== 0" for the child, and the parent never tests for > errors). > > Now, that part is fine. The part that ISN'T fine is when you try to > kill off the children: you will do a "kill(-1, SIGKILL)". Oops. You > just killed off every single process in the system (init, login, etc > etc), and the system is dead.
> > If the same thing doesn't happen under 2.0.36, then the only thing I can > think of is (a) NR_TASKS is larger? or (b) you didn't run it as root. > > Because your program is _supposed_ to kill the system as it is written. > Oh, the dangers of running buggy programs as root. > > [ If you run it as a normal user, you'll just be logged out when you > kill yourself, unless you kill the X server in which case you'll have > to get in through the network and restart it due to the XFree86 > misfeature we all know and love ] > > Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/