> 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
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
> --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
--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
> 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
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 kill
--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 experimental
--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 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 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,
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
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
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
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
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
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;
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
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
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;
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 internal
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 systems ?
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 has a vm
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
23 matches
Mail list logo
