>> Just a thought, but how much memory does root need to do suchlike
>> cleanups? Let's see - load the login shell (probably already in
>> memory anyway, so 0k), run ps (may already be in memory) to find
>> out which processes are currently hogging memory, then kill
>> (usually a shell internal, so 0k) to get rid of a few of
>> them...that should do...
> Too many "propably's". If one of the "propably's" fail, you might
> end up in trouble - or so experience tell me.
True, but the question's a serious one all the same. Just how LITTLE
memory can root get away with to be able to log in, find the rogue
processes, and kill one or two of them to free up memory?
> I ended up in trouble due to Linux being to kind to users
> malloc/calloc/*alloc requests. A lot of 'unable to load ...',
> 'cannot map libc.so. blah, blah, blah' and the like.
Ah...
>> OTOH, what happens if CRON or the like starts up a memory hog as
>> root? Surely those rootpages should be reserved for genuine
>> logons, otherwise the memory in question could easily be taken up
>> by root CRON jobs ???
> Absolutely correct. My sole intention is to keep my users from doing
> "anything stupid" (Ok, broad term!) If root asks for trouble, (s)he
> will get it!
Ah...
> I don't see how (and maybe why) to implement something which would
> ban root from doing something "silly". Contribute that to my lack
> of knowledge with respect to the memory subsystem. I might have
> some ideas on how to implement a '5% Real Genuine Root-reserve',
> but I don't know what options the memory sub-system offers me or
> how flexible the mss is.
Neither do I, unfortunately...
> I'll leave it to others (more proficient) to implement. Hint, hint!
I hope somebody with the relevant knowledge will take that hint up...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/