crash () { crash|crash& }; crash

grob115 · 05-03-2011, 10:36 AM

Sorry I know this would bring the server to its knees if ulimit is not set. However, can someone explain to me why this works.
crash () { crash|crash& }; crash

But either of the following doesn't?

This should recursively calls the function "crash".
crash () { crash }; crash

This should recursively calls the function "crash", except to throw it into the background.
crash () { crash& }; crash

EricTRA · 05-04-2011, 12:08 AM

Hello,

At the following links you'll find all information and explanation about Bash fork bombs you might need:
http://www.cyberciti.biz/faq/underst...ash-fork-bomb/
http://en.wikipedia.org/wiki/Fork_bomb

Kind regards,

Eric

grob115 · 05-05-2011, 10:14 AM

Can you tell me why the following wouldn't work? It's still calling itself recursively and putting the child processes into background.
crash () { crash& }; crash

Also, not sure why the following would regain the process table slots as per http://en.wikipedia.org/wiki/Fork_bomb
while (sleep 100 &!) do; done

What is the ! doing? Assuming it's the same as the following, it still is taking back one process slot. And this isn't being released back to the system for an admin to run any commands to kill the bomb.
while (true) do; done

unixfool · 05-05-2011, 10:42 AM

I'm lost.

What are you trying to do? Create a fork bomb, prevent a fork bomb, or just understand the makings of a fork bomb?

The reason I'm asking is that I dunno if it would be kosher to assist you with creating a fork bomb. Preventing one might be doable, along with helping one comprehend.

But this applies to zsh but it may well apply to bash also:

Quote:

According to that Wikipedia article, the purpose of the complete command is to create many harmless jobs that will disable the fork bomb because it will no longer able to spawn even more children.

According to the zsh manual,

If a job is started with &|' or &!', then that job is immediately disowned. After startup, it does not have a place in the job table, and is not subject to the job control features described here.

I am not sure how to achieve the same with bash. However, something like the following might do:

nohup sleep 100 &

Then the post after it:

Quote:

Hi guys, I'm the guy who wrote that part of the Wikipedia article (and who "discovered" this cure after accidentally starting the fork bomb on my system!).

The reason for the "&!" instead of "&" is indeed to prevent zsh from doing job-control over the new process, i.e., trying to care when and if it finished. I don't remember exactly why job control was a problem when I tried it, but it was. You can actually try it to see how the "cure" works and what happens if you don't prevent job control. Maybe the problem with job control had to do with some bug in zsh that doesn't even exist in bash, and maybe it is no longer relevant in zsh either.

So try just an "&" with bash, and if job control is interfering, try to disable it ("set +m") and hopefully this would work.

You're right that the wikipedia article should probably not be zsh dependent.

anon237 · 05-05-2011, 10:48 AM

Hi,

This crash () { crash& }; crash does "work". Its just not fast enough to do any real harm.

Open 2 terminals, start top in one and the following in the other: crash () { sleep 1 ; crash& }; crash

You'll see the sleep command and a bash session that change pid every 1 second and this will go on forever. Without the sleep 1 it will run for a short while before it is killed by the system. It is just not fast enough.

The original command multiplies very fast (1, 2, 4, 8, 16 etc.) and overwhelms the system if no precautions are taken.

Hope this clears things up.

grob115 · 05-06-2011, 10:09 PM

druuna, thanks. I get what you say.

anon237 · 05-07-2011, 03:06 AM

You're welcome