On Wed, 24 May 2000, Jesse Pollard wrote:
> 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).
Or, with Apache at least, once you SIGTERM the parent (for which the PID
is logged anyway), it automatically SIGTERMs the children for you. It
might take a while to hit them all, if the load average is in three
figures, but it will get them - it already knows their PIDs, and can just
iterate through SIGTERMing them all. (It will also stop forking new
processes immediately, which is the key point.)
If it's a bona fide forkbomb, of course, you don't have this. Being able
to make fork() a privileged operation in these circumstances could be
useful here? (A simple "echo 1 > /proc/sys/kernel/disable_non_root_fork"
or whatever, then you can "killall forkbomb" and it's fixed.) No use if
the forkbomb is running as root - but then, if root has been compromised
like that, you have big problems anyway.
James.
-
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