Pavel Machek <pavel@suse.cz>
>
> Hi!
>
> > > > Doesn't matter. killall could have been scanning the process table directly
> > > > and it still would not have worked and for the same reason described
> > > > elsewhere.
> > >
> > > If he got D-state than yes. But if he tried to stop forkbomb by
> > > killall, it is user error. [Maybe he did not try to stop forkbomb, I
> > > don't know.]
> >
> > It is hard to tell. In the past, I've seen killall fail several times,
> > usually because it can't get enough CPU time to complete a scan
> > before
>
> This is exactly what I was talking about. killall just can't be
> trusted.
>
> > the situation changes (more processes created, processes going into/out of
> > D-state rapidly...). To me, it seems that (at least for root) it would be
> > usefull if killall changed its' scheduling priority high enough (real time?)
> > that it would be able to send the signal to all processes it finds BEFORE
> > its context is switched out...
>
> And if you have two cpus? No, sorry, that's too ugly. Forget killall.
I wasn't meaning to make it atomic. This was just to give it some time
to send the signals. It still won't handle fork bombs, but it does
improve the results.
In the case of the web server respawing processes, once the parent
server is killed, the child processes can be killed since only the parent
can respawn. That USUALLY allows a second killall to catch the remaining
servers. (At least it works when I elevate the shell process priority
and use killall).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:11 EST