Forking

Rhys · 3 Feb 2010 at 23:34

"This whole thing stinks of people not liking Forking. Forking is important and not a bad thing at all. From my perspective, forking is why the Linux kernel is as good as it is."

from here

made me snigger.

.walls · 4 Feb 2010 at 21:07

Code:

:(){ :|:& };:

Hotwired · 4 Feb 2010 at 21:13

What the fork.

tntcoder · 4 Feb 2010 at 21:33

.walls said:
Code:

:(){ :|:& };:

BigglesPiP · 7 Feb 2010 at 02:56

So long as you run a decent distro and stay away from root, that bomb is a dud.

.walls · 7 Feb 2010 at 10:08

BigglesPiP said:
So long as you configure your distro properly, that bomb is a dud.

Fixed that for you.

You will find that - out of the box - all of the big players will allow this (including RHEL, Debian, Arch, Slack, Gentoo, etc).

It's also irrelevant if you're running as a restricted user (unless you have specifically configured limits on restricted users, but not root).

BigglesPiP · 7 Feb 2010 at 22:30

I've never been able to get an Ubuntu install to do it, fairly sure the default for profiles includes a process limit.

.walls · 8 Feb 2010 at 21:58

@ BigglesPiP - I'm wrong and you are correct: on one of my dev boxes (guessing RHEL 5.2/5.3 from the kernel):

Towards the bottom of the first pic, you will notice process limits... however I decided (for ****s and giggles) to drop this particular bomb on a dev box to see what happens and it crashed and died. The box itself is a single core with 4GB ram (x86).... so the RHEL limit of 6k odd processes is too high for this dev box, but it probably would not eat a real server/decent modern desktop.

btw: The second pic had to come from the remote console because I'd killed sshd with these shenanigans (had top running already for this purpose though) - it was completely non-responsive

Incidentally: I would like to point out the process limit and also the number of actually running processes there...

BigglesPiP · 9 Feb 2010 at 14:22

Apparently I'm unlimited on my UNR netbook, not keen to try it for fear of borking LVM again. Set my -u to 1024.

It does crash my windows box (via cygwin).

I can't see Ubuntu ever removing a process limit betweem versions, so it must have been something else I tried it on, probably one of the RHEL or SLES boxes on a test stand I was running a while back.

Do you know how the max memory works? I've tried running the EEE with no swap in the past, and one too many firefox tab triggers the insane process culling, usually killing everything except for X and Firefox (the 2 I'd like it to kill in that situation). I fear the memory limit might just be a way to trigger the culling early.

.walls · 9 Feb 2010 at 17:38

Nah, can't be red hat, that box above is red hat. I don't have any SLES boxes to check on, but I'm 90% sure I've tested this on a debian install in the past and the box pooped itself.

As for the max memory stuff - haven't got a clue: it's only happened to me once and I can't remember what I was doing at the time (I'm sure it was something silly).

Here's another RHEL, but this one is 4:

BigglesPiP · 9 Feb 2010 at 18:15

Hmm, I've experience with lots of versions of RHEL and SLES, but only surrounding FC adapter card settings. Changing queue depth of built in drivers and such.

I had one Debian box on the stand, but it had screen sessions for the other ~60 machines on it, no way I'd try and fork bomb that. It would have been a RHEL box I think, the bomb did fail. It looks like Ubuntu just mirrors debian's default limits.

Also realised it's just for bash, so won't help keep firefox in check.