[3791] in testers
Re: more xlogin stderr fun
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jul 16 13:30:44 1998
Date: Thu, 16 Jul 1998 13:30:35 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: Dan Winship <danw@MIT.EDU>
Cc: testers@MIT.EDU
In-Reply-To: "[3782] in testers"
I have More Data (tm) on this problem.
On Solaris, when dm starts up the console process, it creates a pipe
(the output fd of which is 3, as it happens), opens /dev/console, and
invokes ioctl(SRIOCSREDIR) on the console fd to repoint it at the
input descriptor of the pipe. Then it runs console with "-inputfd 3".
console will now read input from both fd 0 (which is set to /dev/ttyp0
and which is where xlogin writes its output to) and fd 3.
If, however, console ever gets a 0 or -1 return from read() in either
fd, it will stop reading from it. The current status of console on
implementor (which is in the failure state) is that console is no
longer reading from fd 3. Thus, no one is reading output from
/dev/console and any process which tries to output there hangs.
This explains:
* Why xlogin can get output written to the console window
while other processes are busily hanging trying to do the
same thing.
* Why output to /dev/console isn't getting read in the failure
state.
* Why after Dan logs in, the detach process completes (he
presumably does a config_console, causing dm to restart the
console process).
It doesn't explain:
* Why the output of the detach process is going to
/dev/console. (Unfortunately, xlogin has killed the
reactivate process on implementor so I can't see whether the
output of the reactivate script is going to /dev/console.)
* Why console is getting a 0 or -1 read from fd 3 at any
point. It could be that some process is doing a write(...,
..., 0) to the console. We should be able to narrow down
the list of suspects by adding a "set -x" to reactivate on a
machine which experiences the problem. I've done this on
implementor.
* Under what conditions this failure mode arises.
I'm also very curious why dm redirects console output to a pipe
instead of just pointing it at consolefd (ttyp0).
I will submit a workaround for 8.2.8 in console which will work
assuming that some process is just doing a zero-length write to the
console. It will also add some error output in case the problem is
more severe.
