djc@chinet.UUCP (David J. Carpenter) (09/05/85)
I have experienced a bizzare problem with logging in on the console on our 3b2. Here's what would happen: Unix: would send login: , I would reply, then Unix would send Login incorrect immediately without asking for a password. I immediately feared that something happened to /etc/passwd. But I went to other terminals and was able to login without any problem. Then I found that the console would allow me to login as guest, which didn't have a password, but from guest, su replied with Sorry without asking for a password. When on as guest, the ps command reported that my login -sh was not associated with a terminal. The only major change I had recently made of significance was to change a line in /etc/inittab from a uugetty to a shell script that did a few things, then exec'd uugetty. Doing a ps from another terminal revealed that this shell script was associated with console. So apparently, for some reason INIT made the shell script in console group, and when login started up on the console it didn't like having another process associated with console and got suspicious. Switching back the /etc/inittab line solved the problem. Anybody know anything about this? Thanks... -- ...!ihnp4!chinet!djc David Carpenter (312) 545-8076
smb@ulysses.UUCP (Steven Bellovin) (09/06/85)
> I have experienced a bizzare problem with logging in on the console > on our 3b2. Here's what would happen: Unix: would send login: , I > would reply, then Unix would send Login incorrect immediately without > asking for a password. I immediately feared that something happened > to /etc/passwd. But I went to other terminals and was able to login > without any problem. Then I found that the console would allow me to > login as guest, which didn't have a password, but from guest, su > replied with Sorry without asking for a password. When on as guest, > the ps command reported that my login -sh was not associated with > a terminal. > The only major change I had recently made of significance was > to change a line in /etc/inittab from a uugetty to a shell script > that did a few things, then exec'd uugetty. Doing a ps from another > terminal revealed that this shell script was associated with console. > So apparently, for some reason INIT made the shell script in > console group, and when login started up on the console it didn't like > having another process associated with console and got suspicious. > Switching back the /etc/inittab line solved the problem. It's not a matter of suspicion or paranoia; rather, because something else had the console open first the getty for it didn't get the proper process group, and hence getpass() couldn't open /dev/tty. I've seen this once or twice myself; rebooting made the problem go away.
gdsd1@homxb.UUCP (N. Nuckolls) (09/06/85)
> I have experienced a bizzare problem with logging in on the console > on our 3b2. Here's what would happen: Unix: would send login: , I > would reply, then Unix would send Login incorrect immediately without > asking for a password. Yep, had the same experience on a 3b5 running 5.0.5 a year ago. A non-super user would start a db server process that ignored some signals and setpgrp() to detach from it's controlling terminal. Everything would work great, user would log out, try to log back in later that same day when his/her server was still running and get the problem described above. No problems on VAXen and 3B20S's running 5.0.5. The quick fix was for the server to close all it's open tty descriptors. I never looked further into the 3b5's kernel. -- Neal Nuckolls AT&T Bell Laboratories HR-1A343 480 Red Hill Road Middletown, NJ 07748 ..!{ihnp4|houxa}!speedy!neal (201) 949-9295
david@ukma.UUCP (David Herron, NPR Lover) (09/06/85)
In article <174@chinet.UUCP> djc@chinet.UUCP (David J. Carpenter) writes: >I have experienced a bizzare problem with logging in on the console >on our 3b2. Here's what would happen: Unix: would send login: , I >would reply, then Unix would send Login incorrect immediately without >asking for a password. I immediately feared that something happened >to /etc/passwd. But I went to other terminals and was able to login >without any problem. Then I found that the console would allow me to >login as guest, which didn't have a password, but from guest, su >replied with Sorry without asking for a password. When on as guest, >the ps command reported that my login -sh was not associated with >a terminal. > The only major change I had recently made of significance was >to change a line in /etc/inittab from a uugetty to a shell script >that did a few things, then exec'd uugetty. Doing a ps from another >terminal revealed that this shell script was associated with console. We've experienced this EXACT SAME problem on some of our 3B2's. BUT, we haven't put any kind of shell script on our console but are running getty (not uugetty). In fact, on one of these machines we aren't running uugetty ANYWHERE. We traced the problem to an inability for /dev/tty to be opened if you're logged in on the console. getpass() usually opens /dev/tty to get the password, so that routine will fail. (Though, doesn't the 4.2 getpass() try other things if /dev/tty fails? I don't recall too well). Unfortunately we can't fire up the machine again because it's sitting in the other room with no software, waiting for ATTIS to bring us a fresh core pack. (There's another problem in the machine where it's trashing core packs ... anybody else have that problem?) -- --- David Herron --- ARPA-> ukma!david@ANL-MCS.ARPA --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david --- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david Hackin's in me blood. My mother was known as Miss Hacker before she married!
pat@pyuxqq.UUCP (Pat M. Iurilli) (09/06/85)
A similar occurrence happened to me a few times, but for a different
reason. I had just done some work on an ACU on the contty port and
accidentally knocked the shield ground wire off the ground lug on the
console port. I got the exact same phenomena about login not asking
for a passwd, then saying login incorrect. all was fixed when i
reconnected the ground wire. I have been told that all the I/O ports
on the 3b2 will work fine with or without the shield ground wire
attached, but i can recreate the problem any time by just removing the
wire, so I guess something's flakey. Anyone else have any ideas?
--
Pat M. Iurilli Bell Communications Research Piscataway, NJ
{allegra, ihnp4}!pyuxqq!patsean@ukma.UUCP (Sean Casey) (09/07/85)
In article <174@chinet.UUCP> djc@chinet.UUCP (David J. Carpenter) writes: >I have experienced a bizzare problem with logging in on the console >on our 3b2. Here's what would happen: Unix: would send login: , I >would reply, then Unix would send Login incorrect immediately without >asking for a password. >... We had the same problem here, that is, until our 3b2 died altogether. I tracked it down to the routine getpass(), which was returning a null password because it couldn't open /dev/tty. For some reason, only the console couldn't open /dev/tty. When I talked to AT&T, he explained that the console was driven by a "pseudodriver" and the problem was probably in the driver. When I asked how the driver could suddenly go bad, he responded "file system corruption", and told me to do a partial restore. So maybe doing a partial restore would help. We didn't get to, because our machine refused to boot from floppy, and a long chain of problems ended up in a complete reformat and reload, but the reload didn't take for some reason and now we have a quite dead 3b2. I really don't buy the technician's excuse, but at this point, it doesn't really matter. -- - Sean Casey UUCP: sean@ukma.UUCP or - Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean - University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPA
sean@ukma.UUCP (Sean Casey) (09/07/85)
I also should point out that rebooting did not solve our problem.
Sean
--
- Sean Casey UUCP: sean@ukma.UUCP or
- Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean
- University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPArt@cpsc53.UUCP (Ron Thompson) (09/08/85)
> > I have experienced a bizzare problem with logging in on the console > > on our 3b2. Here's what would happen: Unix: would send login: , I > > would reply, then Unix would send Login incorrect immediately without > > asking for a password. > > Then I found that the console would allow me to > > login as guest, which didn't have a password, but from guest, su > > replied with Sorry without asking for a password. When on as guest, > > the ps command reported that my login -sh was not associated with > > a terminal. > > It's not a matter of suspicion or paranoia; rather, because something else > had the console open first the getty for it didn't get the proper process > group, and hence getpass() couldn't open /dev/tty. I've seen this once or > twice myself; rebooting made the problem go away. This has also happened on a couple of occaisions with me. I think there is possibly a wrong option in gettydefs that causes the login shell not to die on hangup? I don't think this problem is peculiar to console or 3b2 - more like Sys V. What seemed to have happened with me was I got logged back in on the phantom login. I do not have to re-boot however, just kill that process and login.