User: Password:
|
|
Subscribe / Log in / New account

Fighting fork bombs

Fighting fork bombs

Posted Mar 31, 2011 23:31 UTC (Thu) by mrons (subscriber, #1751)
Parent article: Fighting fork bombs

I administer a system shared by comp sci students and see a lot of fork bombs.

Sending a signal to the process group kills all fork bombs in my experience.

A signal to the process group also kills what we call "comets", a process that forks then exits. You can never catch a PID to kill the comet directly. They can even be hard to detect on a busy system. lastcomm process logs are often the only way to see one.

The other requirement is process limits on users. Fork bombs will make a system unusable if there are no limits.

I don't really see the need for this patch in the kernel. The current facilities of process groups and user process limits solve all the problems that I've seen.


(Log in to post comments)

Fighting fork bombs

Posted Apr 1, 2011 0:29 UTC (Fri) by dtlin (✭ supporter ✭, #36537) [Link]

A process can easily setsid() and make itself a session and process group leader, escaping kill(-pgid) in the same way that fork() escapes kill(pid).

RLIMIT_NPROC/ulimit -u is good, though.

Fighting fork bombs

Posted Apr 1, 2011 0:57 UTC (Fri) by mrons (subscriber, #1751) [Link]

Yes process limits are the most useful tool.

To kill a fork bomb that you can't send a kill(-pgid), you need to send
a STOP signal to each of the processes. The fork bomb won't grow past the users process limits and a STOPped process can't fork. So once all the processes are stopped you can KILL them.

Many years ago we had a lot of fun here in an fork bomb arms race. That's where several forms of "comets" mentioned above were invented in an effort to find something that the sys admin (me) could not kill.

One neat way to kill a comet, is to create a fork bomb as the user of the comet! That will slow down the comet enough so you can STOP it. Then you kill the fork bomb in the usual way.

Fighting fork bombs

Posted Apr 4, 2011 15:35 UTC (Mon) by jeremiah (subscriber, #1221) [Link]

so why not have this fork bomb killer use the limits data to know when a fork bomb has gone off and kill it. I guess to me it seems like if something is constantly bumping up against a limit, there must be something wrong going on, and some configurable action could take place. This seems better than some sort of time based polling mechanism.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds