dave@ucms.UUCP (Dave Settle) (01/06/89)
I'm having intermittent problems with 'login' on System V machines. It's happened on a number of machines, ranging from AT&T 3B2's to more flavoursome versions of SVR2. What happens is that in some circumstances, I can only login using an account without a password. If I try to login as a user who has a password, I get: Machine XYZ .... etc login: dave Login incorrect login: This affects every user who has a password, but only affects the one terminal - I can login on other terminals fine (it asks for my password as per usual). Poking around the system, in particular looking at the 'ps' output, it looks as though a process which normally runs in the background (but occasionally writes output to this terminal) has become attached to the terminal (TTY shows '002' [or whatever]), but the getty process has not (TTY line shows '?'). "Maybe this is to do with process groups and controlling ttys", I think to myself, "I'll go read the manual ... ". However, the manual is less than terrifically helpful. In fact, it is exceedingly cagey about controlling ttys and how they get assigned (and de-assigned). If I knew how to get rid of one, then I could run my background process without it messing up the login procedure. Any help appreciated. Cheers, Dave Settle -- Dave Settle, Universal (CMS) Ltd, Thames Tower, Burleys Way, Leicester, UK. dave@ucms.co.uk ...mcvax!ukc!nott-cs!ucms!dave <--- This way to point of view --->
clewis@ecicrl.UUCP (Chris Lewis) (01/08/89)
In article <176@ucms.ucms.uucp> dave@ucms.UUCP (Dave Settle) writes: >What happens is that in some circumstances, I can only login using an account >without a password. If I try to login as a user who has a password, I get: >Machine XYZ .... etc >login: dave >Login incorrect >login: >This affects every user who has a password, but only affects the one terminal - >I can login on other terminals fine (it asks for my password as per usual). I've seen this occur a couple of times on 386/ix - to confirm, after successfully logging in on the port that's acting wierd, do this: echo hello > /dev/tty Ours comes back with "can't open". Killing everything in sight on that line usually helps. Used to get it with a serial device driver we hadn't got working w.r.t. setting process groups. [The reason why this relates is that login can't stty -echo when ttyname or isatty fails which they will do if /dev/tty won't open] -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
dave@stcns3.stc.oz (Dave Horsfall) (01/19/89)
In article <176@ucms.ucms.uucp> dave@ucms.UUCP (Dave Settle) writes: | | I'm having intermittent problems with 'login' on System V machines. It's | happened on a number of machines, ranging from AT&T 3B2's to more | flavoursome versions of SVR2. | [ Details suppressed ] This is caused by a process doing a setpgrp() to detach itself from the controlling TTY, and the kernel not getting it right. Subsequently, "login" attempts to disable echo with ioctl(), and fails. A work-around is a liberal application of "fuser -k /dev/tty??" to kill it. If that fails, there's a little switch on most machines... Complain to your vendor, and if possible supply a little program that demonstrates it. We had the problem with CCI 6/32 Unix V for a long time, and it finally got fixed in 2.22.02. -- Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz dave%stcns3.stc.oz.AU@uunet.UU.NET, ...munnari!stcns3.stc.oz.AU!dave PCs haven't changed computing history - merely repeated it