Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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
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
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.