From: ebiederm+eric@ccr.net (Eric W. Biederman)
To: jfm2@club-internet.fr
Cc: sct@redhat.com, linux-mm@kvack.org
Subject: Re: Two naive questions and a suggestion
Date: 25 Nov 1998 08:48:01 -0600 [thread overview]
Message-ID: <m1af1fde1q.fsf@flinx.ccr.net> (raw)
In-Reply-To: jfm2@club-internet.fr's message of "24 Nov 1998 21:44:32 -0000"
>>>>> "jfm2" == jfm2 <jfm2@club-internet.fr> writes:
jfm2> Say the Web or database server can be deemed important enough for it
jfm2> not being killed just because some dim witt is playing with the GIMP
jfm2> at the console and the GIMP has allocated 80 Megs.
jfm2> More reallistically, it can happen that the X server is killed
jfm2> (-9) due to the misbeahviour of a user program and you get
jfm2> trapped with a useless console. Very diificult to recover. Specially
jfm2> if you consider inetd could have been killed too, so no telnetting.
jfm2> You can also find half of your daemons, are gone. That is no mail, no
jfm2> printing, no nothing.
initd is never killed. Won't & can't be killed.
initd should be configured to restart all of your important daemons if
they go down.
Currently most unix systems ( I don't think i'ts linux specific) are
misconfigured so they don't automatically restart their important
daemons if they go down.
jfm2> In situation like those above I would like Linux supported a concept
jfm2> like guaranteed processses: if VM is exhausted by one of them then try
jfm2> to get memory by killing non guaranteed processes and only kill the
jfm2> original one if all reamining survivors are guaranteed ones.
jfm2> It would be better for mission critical tasks.
Some. But it would be simple and much healthier for tasks that can be
down for a little bit to have initd restart the processes after they
go down. That allows for other cases when the important system
daemons goes down, is more robust, and doesn't require kernel changes.
Eric
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next prev parent reply other threads:[~1998-11-25 14:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-11-19 0:20 jfm2
1998-11-19 20:05 ` Rik van Riel
1998-11-20 1:25 ` jfm2
1998-11-20 15:31 ` Eric W. Biederman
1998-11-23 18:08 ` Stephen C. Tweedie
1998-11-23 20:45 ` jfm2
1998-11-23 21:59 ` jfm2
1998-11-24 1:21 ` Vladimir Dergachev
1998-11-24 11:17 ` Stephen C. Tweedie
1998-11-24 21:44 ` jfm2
1998-11-25 6:41 ` Rik van Riel
1998-11-25 12:27 ` Stephen C. Tweedie
1998-11-25 13:08 ` Rik van Riel
1998-11-25 14:46 ` Stephen C. Tweedie
1998-11-25 16:47 ` Rik van Riel
1998-11-25 21:02 ` Stephen C. Tweedie
1998-11-25 21:21 ` Rik van Riel
1998-11-25 22:29 ` Stephen C. Tweedie
1998-11-26 7:30 ` Rik van Riel
1998-11-26 12:48 ` Stephen C. Tweedie
1998-11-25 20:01 ` jfm2
1998-11-26 7:16 ` Rik van Riel
1998-11-26 19:59 ` jfm2
1998-11-27 17:45 ` Stephen C. Tweedie
1998-11-27 21:14 ` jfm2
1998-11-25 14:48 ` Eric W. Biederman [this message]
1998-11-25 20:29 ` jfm2
1998-11-25 16:31 ` ralf
1998-11-26 12:18 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1af1fde1q.fsf@flinx.ccr.net \
--to=ebiederm+eric@ccr.net \
--cc=jfm2@club-internet.fr \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox