Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!emory!hubcap!ncrcae!cs-col!vause
From: vause@cs-col.Columbia.NCR.COM
Newsgroups: comp.sys.ncr
Subject: Re: ttyb weirdness
Message-ID: <1990Feb2.195402.18664@cs-col.Columbia.NCR.COM>
Date: 2 Feb 90 19:54:02 GMT
References: <272@psgdc>
Reply-To: vause@cs-col.Columbia.NCR.COM (PUT YOUR NAME HERE)
Organization: Corporate Customer Services NCR E&M Columbia, SC
Lines: 61

In article <272@psgdc> rg@psgdc (Dick Gill) writes:
>I have a client experiencing some real weirdness in connection
>with the ttyb port.  The configuration is a 32/650 (2.01.01)
>...
>The ttyb terminal was at a login, and I entered
>my login name.  After hitting a <RETURN>, the cursor moved down
>a line and to the left, but did not ask for a password.  Another
><RETURN> got me the password prompt and I entered the password,
>again followed by a <RETURN>.  Once again the cursor moved to
>the left and down a line but the system did not respond.  After
>another <RETURN> the system responded that the login was
>invalid and asked for a login again.  Several additional tries
>gave me the same result.
>
>The client said that the only way to straighten out this problem
>was to power the terminal off and on again.  I did powered the
>terminal off and all at once a message from tty? appeared on
>almost all of the other terminals.  The content of the message
>was the keystrokes I had entered in trying to log in, including
>my user name, password and all of the CR/LF sequences!  Upon
>powering up again I was able to login normally, but soon hit the
>same situation where the <RETURN> key did not work properly. 
>Upon turning the terminal off and on again, more messages were
>sent to the other terminals.

Well, it sounds like there is an evil daemon (:-}) at work  here:
if there is some process which keeps /dev/console (or whatever it
is called at that point, since there are usually  three  or  more
links)  open,  there  is  a  tendancy  for the open of "/dev/tty"
within the /bin/login-getpass.o  subroutine  to  fail,  since  it
cannot  complete  the open.  Most of the times, we have seen some
daemon process perform an exclusive open  on  the  /dev/tty  node
(the  console,  in this case, since the process is started during
the  single-to-multi-user  state  change),   which   blocks   all
password-protected users from login activities.

The usual scenario is just as  you  have  described,  albeit  the
total  cycle  is  usually fairly quick.  In your case, it appears
the daemon(s) are system hogs, and are not giving the  /etc/init-
>/etc/getty programs very much CPU times between cycle events.

Suggestions?   Try  turning  off  all   daemon   activities   (in
/etc/inittab  and  /etc/rc),  and  bring  them  up one at a time,
layering 'em so to speak,  in  order  to  isolate  the  offending
program.

Good Luck!--this can be one of the most irritating  situations to
try  to  debug, and the solution is too frequently to re-code the
daemon... (:-{ )!

Anyone else have suggestions for this good man?

						--sam

+---------------------------------------------------------------+
|Sam Vause, NCR Corporation, Customer Services - TOWER Support  |
|3325 Platt Springs Road, West Columbia, SC 29169 (803) 791-6953|
|                                vause@cs-col.Columbia.NCR.COM  |
|                         ...!uunet!ncrlnk!ncrcae!cs-col!vause  |
|                ...!ucbvax!sdcsvax!ncr-sd!ncrcae!cs-col!vause  |
+---------------------------------------------------------------+