Re: PROPOSAL: defining a new runlevel, 4
In article <[🔎] E0yVex8-0002E4-00@burrito.onshore.com>,
Adam P. Harris <apharris@onshore.com> wrote:
>
>"Hamish" == Hamish Moffatt <hamish@debian.org> writes:
>> On Sat, May 02, 1998 at 04:15:54AM -0400, Adam P. Harris wrote:
>> But hang on; Branden's whole point was that runlevels could solve
>> the xdm & xfs mess in the /etc/X11/config file; your runlevel
[...]
>
>I'm not adverse to having xdm/xfs et al start in run level 4, that is
>fine. In that case, we're extending tradition a little.
I'd like to pitch in here and say that I think that treating xdm (and
xfs) differently from other network services is the wrong way of fixing
the problem. (I'm assuming the problem you're trying to fix is that of
how to cleanly get rid of the console X server while you're not using it,
or while you're trying to fix it (as in bug 15898).)
I contend that xdm should not be responsible for starting any X server.
xdm is a network service daemon which implements the XDMCP protocol,
similar to the way sshd, innd, sendmail, apache and the like implement
the SSH, NNTP, SMTP and HTTP protocols. xdm should not be started or
stopped just to achieve some effect for the local user. In particular,
this is inconsistent with xdm's use to support X terminals. If the local
user was having problems with a badly-configured console X server and
stopped xdm (by, say, changing run level) to fix the problem, all the
X terminals' sessions would be terminated, too.
Instead, I'd like to see xdm doing just what it was intended for, and
not playing at being init. (It currently does that, by restarting the
X server whenever it dies.) This is a Bad Thing, IMO. In particular,
xdm doesn't attempt to throttle-back when the X server dies consistently.
init already knows how to do that; it's not "the unix way" to reinvent
the functionality for xdm.
I proposed the setup I currently use in bug 15897 but it's not really
a general solution yet. It needs some work to make it properly
configurable. I'll try to do this sometime, but it may not be soon,
because I'm busy with my PhD just now (process algebras and behavioural
subtyping, in case anyone's interested in knowing that...) If anyone else
would like to work up something practical based on this idea, please do.
I think our heroic X maintainer has enough to do already...
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: