rgc@wam.umd.edu (Ross Garrett Cutler) (07/20/90)
Hello, We have a DS3100 w/8 MB of RAM, Ultrix 3.1d, running DECWindows. We are having login problems of the following sort: 1. If you login from the console after it hasn't been used for several hours, it let's you enter your user-id, pw, then churns away for 15 seconds...and then comes back to the login prompt! It requires several attempts to login successfully. 2. Remote (telnet) logins work fine. 3. Logins immediately after someone has used it also work fine. A DEC person suggested that the $term variable == none sometimes (instead of vt300), and that we shouldn't do any reads from the terminal (e.g. biff) if this is true. She did not ofter a better solution, so I was wondering if anyone else has experienced this strange occurence. I have verified that $term is indeed none after some period of console inactivity. Ross. -- Ross Cutler University of Maryland, College Park Internet: rgc@wam.umd.edu
cs225bf@ux1.cso.uiuc.edu (07/20/90)
I've had the same thing happen on a DS2100. ....I can't explain it either. Duane Setterdahl University of Illinois
eric@batcomputer.tn.cornell.edu (Eric Fielding) (07/21/90)
In a recent article rgc@wam.umd.edu (Ross Garrett Cutler) wrote: > We have a DS3100 w/8 MB of RAM, Ultrix 3.1d, running DECWindows. >We are having login problems of the following sort: > 1. If you login from the console after it hasn't been used for > several hours, it let's you enter your user-id, pw, then > churns away for 15 seconds...and then comes back to the > login prompt! It requires several attempts to login successfully. >... >so I was wondering if anyone else has experienced this strange occurence. >I have verified that $term is indeed none after some period of console >inactivity. Ross. We have the same problem here on a 12 MB DECstation. It seems to help alot to hit the "clear" button on the login window before trying to log in. I think that someone said that it had to do with some process getting swapped out perhaps several months ago when there were some postings on this. I never looked at the $term variable. There was also a suggestion that there was a timer that counts the time between typing the user name and password that denies access if the time is too long. And if things are moving slowly due to paging or swapping, then it is more likely to happen. ++Eric Fielding eric@geology.tn.cornell.edu
D. Allen [CGL]) (07/21/90)
>There was also a suggestion that there was a timer that counts the time >between typing the user name and password that denies access if the time >is too long. Here's what I said last March: From idallen Sat Mar 31 02:53:46 1990 To: comp.unix.ultrix This binary: ULTBASE031.inv:0000 68608 15096 0 0 104755 5/2/89 031 f ./usr/bin/login none ULTBASE031 presumably made from this Ultrix 3.1 source: static char *sccsid = "@(#)login.c 9.5 (ULTRIX) 5/1/89"; This change: * 029 - Gary A. Gaudet. Fri Apr 21 21:57:43 EDT 1989 * Added unbuffered stdin, cyphered name and password, * and bzero buffer, for -P. is wrong. It unbuffers stdin between two fgets() calls, causing pending stuff to be lost and Xprompter to fail. Putting a call to setbuf() to do the unbuffering before the first fgets() fixes things. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada