Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!ncrcae!ncrlnk!ncrcce!mercer From: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) Newsgroups: comp.sys.ncr Subject: Re: ttyb weirdness Message-ID: <1873@ncrcce.StPaul.NCR.COM> Date: 5 Feb 90 06:03:13 GMT References: <272@psgdc> <263@ncrwat.Waterloo.NCR.COM> Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) Organization: NCR Comten, Inc. Lines: 52 Keywords: 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 , the cursor moved down := a line and to the left, but did not ask for a password. Another := got me the password prompt and I entered the password, := again followed by a . Once again the cursor moved to := the left and down a line but the system did not respond. After := another 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)