> On Wed, Mar 28, 2001 at 06:33:04PM -0500, Hacksaw wrote:
> Why are they logged in as root in the first place? Is there something they
> can't do over sudo?
I have the "Gnome workstation" version of rawhide (7.0.xxx) on my new laptop.
I don't see sudo. Of course, it's rawhide, but you'd think,
On Wed, Mar 28, 2001 at 06:33:04PM -0500, Hacksaw wrote:
> > Anyone working as root is (sorry) an idiot! root's processes are normally
> > quite system-relevant and so they should never be killed, if we can avoid
> > it.
>
> The real world intrudes. Root sometimes needs to look at documentation
> --On Wednesday, March 28, 2001 09:38:04 -0500 Hacksaw <[EMAIL PROTECTED]>
> wrote:
> >
> > Deciding what not to kill based on who started it seems like a bad idea.
> > Root can start netscape just as easily as any user, but if the choice of
> > processes to kill is root's netscape or a user's
--On Wednesday, March 28, 2001 09:38:04 -0500 Hacksaw <[EMAIL PROTECTED]>
wrote:
>
> Deciding what not to kill based on who started it seems like a bad idea.
> Root can start netscape just as easily as any user, but if the choice of
> processes to kill is root's netscape or a user's experimenta
> a. don't kill any task with a uid < 100
>
> b. if uid between 100 to 500 or CAP-SYS equivalent enabled
> set it too a lower priority, so if it is at fault it will happen slower
>
> giving more time before the system collapses
Deciding what not to kil
I'm going to be gentle here and try to point out where your suggestions are
flawed...
>a. don't kill any task with a uid < 100
Suppose your system daemon springs a leak? It will have to be killed
eventually, however system daemons can sensibly be given a little "grace".
Also, the UIDs used by a
On Tue, 27 Mar 2001, Doug Ledford wrote:
> Now, I wouldn't bring this up as a big issue except I keep seeing
> people say things like "why so complex a solution for something that
> is only used in emergency situations". My point is that it *IS NOT*
> being using only in emergency situations and
Rik van Riel wrote:
>
> On Tue, 27 Mar 2001, Doug Ledford wrote:
>
> > I've been using our internal tree for my testing, and I'm reluctant to
> > let my experiences there cause me to draw conclusions about other
> > trees. So, will you please tell me which version of the kernel you
> > think ha
On Tue, 27 Mar 2001, Doug Ledford wrote:
> I've been using our internal tree for my testing, and I'm reluctant to
> let my experiences there cause me to draw conclusions about other
> trees. So, will you please tell me which version of the kernel you
> think has a vm that only triggers the oom k
On Tuesday 27 March 2001 18:52, Rik van Riel wrote:
> On Tue, 27 Mar 2001, james wrote:
> > Here are my ideas on how too deal with the oom situation,
> >
> > I propose a three prong approach too this problem
>
> Isn't that a bit much for an emergency situation that never
> even occurs on most syst
Rik van Riel wrote:
>
> On Tue, 27 Mar 2001, james wrote:
>
> > Here are my ideas on how too deal with the oom situation,
>
> > I propose a three prong approach too this problem
>
> Isn't that a bit much for an emergency situation that never
> even occurs on most systems ?
I've been using our
On Tue, 27 Mar 2001, james wrote:
> Here are my ideas on how too deal with the oom situation,
> I propose a three prong approach too this problem
Isn't that a bit much for an emergency situation that never
even occurs on most systems ?
Rik
--
Virtual memory is like a game you can't win;
Howeve
Hi Kernel Guru's
Here are my ideas on how too deal with the oom situation, most of these
should be thought of stuff to do in 2.5.x kernels, because it touches a lot
of kernel path ways, with possible back porting
once it is tested.
I propose a three prong approach too this problem
Prong 1
13 matches
Mail list logo
