[ On Wednesday, April 26, 2000 at 00:22:35 (-0700), Greywolf wrote: ]
> Subject: Re: /etc/rc.d evaluation. 
>
> On Wed, 26 Apr 2000, Greg A. Woods wrote:
> 
> # OOPS, no, that might not quite work -- Xstartup is only run after the
> # user authenticates successfully (i.e. long after the X server is already
> # running).  Hmmm... perhaps it's just as easy to wrap the Xserver itself
> # with a little script that uses ttylock to kick getty off the console
> # while X11 runs....
> 
> No, this is not correct either.  The correct behaviour would be to
> have xdm -- or at least xconsole -- hold off until the getty goes, rather
> than trying to stop the getty from running.  I'd like to be able to
> hit ^R to stop my server and go to a getty right there, i.e. start typing,
> instead of waiting for init to figure out that Oh X Has Died I Think I'll
> Start A Getty There Now.  i.e. what I was able to do before rc.d fscked
> it all up.

But that will work with a wrapper script on the Xserver itself!  The
ttylock(3) routine simply blocks the getty [er, uugetty] (immediately in
this case) and as soon as it's unlocked (eg. when the Xserver dies the
wrapper script will simply unlock the tty) then the getty will continue
and print its "login:" prompt.

I think you're confusing things.  I definitely didn't mention anything
about init or the rc.d stuff (which doesn't *cause* this problem --
though it may exacerbate it).

I don't think xconsole should be involved directly in any of this.  It's
job is to simply monitor what appears on the console.

On a sparc when the console is not attached to a serial port it is very
important to run xconsole so that kernel output doesn't mess up the
screen when the kernel console is attached to the framebuffer.  However
it doesn't matter whether you run xconsole or not -- getty shouldn't be
putting a login prompt out either if the Xserver has control of the
framebuffer.  Either one must wrap the Xserver with something that calls
ttylock(3), or do so in xdm before it starts the xserver; and then use
uugetty on /dev/console.

On a system using wscons with multiple virtual consoles on the physical
system console there's no absolute need to run xconsole since the user
can just switch back to whatever virtual screen the console was
originally directed at.  If such a user wants the convenience of having
a window displaying the console messages then they could just as easily
run "xconsole -file /var/log/messages" (despite what the manual says --
it lies and has done so ever since at least June 1997 (XFree86-3.3)!).
There's no need to complicate things with locks and permissions issues
and so on in this scenario.

What I'm still a bit confused about is how /dev/console is implemented
under the hood -- I've looked at sys/dev/cons.[ch], and how that's
reflected in how one manages user-land code that makes use of what we
might call the "console" hardware.  Up until now I've been running getty
on /dev/console on my sparcs because then the same system will give me a
login prompt no matter whether there's a keyboard and framebuffer, or
just a terminal on ttya.  In this case I do want getty to see a
ttylock() when X is running, but iff /dev/console is attached to the
framebuffer and keyboard, but *not* if it's attached to ttya (or ttyb or
whatever).

> If you have this sort of thing dependent on a program, let alone a script,
> if xdm suddenly vanishes or gets kill -KILLd, you're pretty much up the
> creek with no grease.

If the code is in a script then you can be ever more certain that you'll
be able to manually wriggle things should anything "break" unexpectedly.
In fact having the lock functionality reside in a script makes it even
more likely that it'll work *properly* if someone whacks the daemon it's
wrapping!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>