[TAG] Help please :(

[MNZ]

On Wed, Mar 07, 2007 at 09:33:32AM +0000, Thomas Adam wrote:
> That depends.  Under Linux, there's a kernel facet known as the
> OOM-killer (Out Of Memory killer) which will attempt to stop processes
> from becoming all-consuming in their operations.  Whilst the amount of
> memory each child takes up is likely to be small, cumulatively it's
> going to be quite large if a parent continually starts to fork various
> processes off.  The kernel notices this fact and will *try* and kill a
> process of.
> 
> But it's not as as simple as that.  Due to several complex reasons, the
> OOM-killer is rarely able (or unlikely) to kill off the process or
> processes which are becoming a problem.  Hence it's likely that the
> OOM-killer will kill anything off.  This is again potentially a
> nuisance as you can imagine, since it can lead to a number of processes
> being orphaned to init, often in a D or Z state such that the process
> may never recover [1].

Google sayeth:
``
It is the job of the linux 'oom killer' to sacrifice one or more processes in 
order to free up memory for the system when all else fails. It will also kill 
any process sharing the same mm_struct as the selected process, for obvious 
reasons. Any particular process leader may be immunized against the oom killer 
if the value of it's /proc/<pid>/oomadj is set to the constant OOM_DISABLE 
(currently defined as -17).
''

I guess OOM-Killer wasn't made to stop hostile process but rather to stop ones
that take up too much memory on "accident". Or there wouldn't be any 
"immunization" against it

> (--snip--)
> 
> ```
> :(){ :|:& };:
> '''
> 
> (This is specific to bourne shells).  This creates a function called
> ':' which then calls itself recursively, all the time forking a new
> instance.  Can you see now, why in the situation with this proposed
> parent->child forking many processes why this is a bad idea?  It's the
> same thing as the above example -- potentially bad.  
> 
> Again, ulimit can help in this instance.  It's not just memory
> limitations which can mitigate the above.  Ulimit can also limit the
> number of processes a user can run, but even this is still no guarantee
> of control.

Quite interesting, thanks.

> I have no doubt that it's simply the querent's description of what he's
> trying to do -- and even if it's a mis-communication on his part, it's
> still useful that he should have mentioned it.

Cenk Yusuf, if you would like to explain the problem in arabic (guessed from 
your name, but not sure if you speak arabic) I'd be more than happy to 
translate.

-- 
//MNZ\\  "We all need mirrors to remind ourselves who we are"
							-- Leonard Shelby