rg@psgdc (Dick Gill) (02/02/90)
I have a client experiencing some real weirdness in connection with the ttyb port. The configuration is a 32/650 (2.01.01) with 16MB RAM, 8-HPSIO's (8-port), Wyse-50 terminals, 3-SCSI discs, 1-45MB tape, 1-150MB tape and one 9-track tape. The system currently has about 35 users active throughout the day. This problem has been around for months, but I personally incountered it this morning and will try to describe it accurately. 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. NCR has replaced the PMC board and the terminal has been swapped with one that works fine. As a further test, I changed the cables on the back of the Tower and put another terminal (and cable) on the ttyb port; same problem! Any ideas? Thanks Dick Gill
rg@psgdc (Dick Gill) (02/02/90)
Just got some more information from the client on this problem. It seems that the ttyb terminal works just fine in single user mode; they go to single user nightly to do backups. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dick Gill Professional Solutions Group (703)761-1163 ..uunet!psgdc!rg
tbertels@cipc1.Dayton.NCR.COM (Tom Bertelson) (02/02/90)
rg@psgdc (Dick Gill) writes: > 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. I have seen this one before, where an errant program was fighting with /etc/getty for characters from the terminal. The next time it happens try /etc/fuser /dev/ttyb from another terminal. This will return the process ID's of any program using /dev/ttyb. There should only be one - the PID of /etc/getty. Do ps -fp PID and see what the program(s) are. Hope this helps. -- Tom Bertelson DISCLAIMER: My opinions are my own and Tom.Bertelson@Dayton.NCR.COM in no way reflect those of my employer. ...!uunet!ncrlnk!cipc1!tbertels
tmoore@coss.Dayton.NCR.COM (Tom Moore) (02/02/90)
rg@psgdc (Dick Gill) writes: [...] >Any ideas? This sounds very much like two processes trying to read input. Have you checked to see what processes have ttyb open? -- * Tom Moore NCR Corporation PCD-6 (513) 445-1373 * * Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 * * Network Applications Dayton, OH 45479 Tom.Moore@Dayton.NCR.COM *
del@ncrwat.Waterloo.NCR.COM (Douglas E. Lamb) (02/02/90)
In article <272@psgdc>, rg@psgdc (Dick Gill) writes:
= 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.
This sounds like that there's another process talking to the tty.
When more than one process is attempting to read data from the same tty,
keyboard data is given to each process in turn, line by line. The first
line to process 1, the second to process 2, etc. In this case, the login
process appears to be getting every other line, indicating one other
process in the loop.
This can be verified by doing a '/etc/fuser -u /dev/ttyb'. This will return
all processes that have ttyb open for I/O. Beware, however, certain daemons
like 'errdemon' and 'lpsched' tend to have the 'console' open for output.
So look for a process that wouldn't normally be doing I/O to the console.
--
Douglas E. Lamb, Tower/WIN Administrator ---- Doug ----
Information Systems and Services MAILplus: D.Lamb@Waterloo.NCR.COM
E & M Waterloo UUCP: uunet!ncrlnk!ncrwat!del
Waterloo, Ontario, CANADA VOICEplus: 643-1319 (519-884-1710)walt@hisata.UUCP (Walt Hultgren) (02/03/90)
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) >... I don't know if this is relevant, but I have had similar problems logging into User-ID "sa" on ttyb on a Tower 1632. It was happening some time ago (at least one release back), and since I stumbled on the work-around, I haven't seen it since. On occasion, when I logged into sa by using the command "login sa" from the shell on another User-ID, the system would appear to recognize only every other character. I found that if I hit every key twice, things more or less worked. When this problem was occurring, a ps -ef from another terminal would show that there were two separate sa processes with different process ID's listed as running on ttyb. I don't think there were 2 getty's, but everything else was duplicated. I hypothesized that each process was getting every other character from the terminal. The problem seemed to occur only when I used "login sa" to get to sa, though not always. It never occurred if I first logged off of the current User-ID by hitting ^D, then entered "sa" to the login prompt. Since I use sa primarily for operations that require going to single-user or stopping the system, I only use sa on ttyb. So, I don't know if the problem was with sa or ttyb. Since the ^D method has continued to work, I've never investigated it further. Hope this helps. Walt. Walt Hultgren Hultgren Information Systems, P. O. Box 386, Tucker, Georgia 30085 USA Voice: +1 404 564 4707 UUCP: ...!{most_backbones}!gatech!hisata!walt
wescott@Columbia.NCR.COM (Mike Wescott) (02/03/90)
In article <272@psgdc> rg@psgdc (Dick Gill) writes: > 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. > 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 There has got to be some program running that is snarfing up the input from ttyb. Sounds like /etc/wall. Next time the problem occurs, on another tty run /etc/fuser and find out what processes are using /dev/ttyb, /dev/console, /dev/syscon, and /dev/systty. One of those processes is the culprit, probably spawned by /etc/init, one of the startup scripts (/etc/*rc), or a cron(1M) or at(1) job. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM
jalsop@seachg.UUCP (John Alsop) (02/03/90)
rg@psgdc (Dick Gill) writes: >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. This sounds like an interactive shell or other program is running in the background on that terminal. I've seen this happen on our system and it can be a real pain. Basically the background program and the login process take turns reading from the tty, but you never know for sure which one will get which line of input. Try logging in on another terminal and checking what processes are running on the affected port. If this problem persists across a shutdown and reboot, perhaps there is a commonly used program or shell script that is inadvertently starting a background process reading from the terminal.
jalsop@seachg.UUCP (John Alsop) (02/03/90)
Forgot to mention this in my previous reply: Check your inittab entries for ttyb. You might be starting an extra process there, which would cause the problem you described. John Alsop
vause@cs-col.Columbia.NCR.COM (02/03/90)
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 | +---------------------------------------------------------------+
duane@anasaz.UUCP (Duane Morse) (02/03/90)
In article <272@psgdc>, rg@psgdc (Dick Gill) writes: >...... > > 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. No telling what's really going on, but here are a couple of things to look at when the problem next occurs. First, check the inittab entry and verify that ttyb has the usual entry (respawn, running getty, etc.). Second, go to a different terminal and do a 'ps -ftb' to see what the system thinks is running on ttyb. If nothing shows up, do a 'who -l' and see if ttyb shows up in the "login/getty" list. If that doesn't turn up anything useful, do a 'ps -af' and see if anybody is running something suspicious. For instance, a program with the right privileges might be redirecting input from ttyb. Though I haven't tried it myself, it may be that running 'wall' with input directed from ttyb would produce the results you saw. Good luck! -- Duane Morse e-mail: duane@anasaz (or ... asuvax!anasaz!duane) (602) 861-7609
mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (02/05/90)
In article <263@ncrwat.Waterloo.NCR.COM> del@ncrwat.Waterloo.NCR.COM (Douglas E. Lamb) writes: :In article <272@psgdc>, rg@psgdc (Dick Gill) writes: := 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. : :This sounds like that there's another process talking to the tty. :When more than one process is attempting to read data from the same tty, :keyboard data is given to each process in turn, line by line. The first :line to process 1, the second to process 2, etc. In this case, the login :process appears to be getting every other line, indicating one other :process in the loop. : :This can be verified by doing a '/etc/fuser -u /dev/ttyb'. This will return :all processes that have ttyb open for I/O. Beware, however, certain daemons :like 'errdemon' and 'lpsched' tend to have the 'console' open for output. :So look for a process that wouldn't normally be doing I/O to the console. : :-- :Douglas E. Lamb, Tower/WIN Administrator ---- Doug ---- :Information Systems and Services MAILplus: D.Lamb@Waterloo.NCR.COM :E & M Waterloo UUCP: uunet!ncrlnk!ncrwat!del :Waterloo, Ontario, CANADA VOICEplus: 643-1319 (519-884-1710) That won't be adequate. IO could also be redirected from /dev/systty, /dev/syscon, and /dev/console. I have one question: do you have shell layers configured and are you using it? We had some very strange problems with shl when we first used it when people disconnected their tubes after getting thoroughly lost in it (They'd go into shell layers running cu in one layer and another application in another. Then they'd go to the shell from cu, invoke another shell layer, get confused at where they were, invoke cu again, get hosed up in vi because they were invoking vi via shell script (God knows why) and would hit some combination that would cause the parent to kill. Etc etc. Anyways, they were logged in via protocol convertor and would just kill the session, causing DTR to drop. There shell layer session would somehow get transferred to the system console (I think I finally tracked it down to /dev/syscon but my memories fuzzy on that. They could just as easily have fallen through the cracks in the device driver. -- Dan Mercer Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)