glenn@vail.gatech.edu (Glenn Souther) (02/16/89)
We have encountered a critical problem with our general access A/UX machines.
When attempting to login ON THE CONSOLE, after entering the account name,
A/UX responds with an incorrect login message, and again asks "login:"
After hearing that System V has this problem when a process has the console
other than the getty/login. So, I telneted into one of the machines and
looked via ps and sure enough the toolboxdaemon had the console. After killing
and restarting the toolboxdaemon, login worked fine. But the problem continues
to occur. When I check the machines in the morning 15 or so have the
problem.
We have a graphics class using the machines to learn implementation of graphics
using simple quickdraw calls, and had not seen the problem until they started
using the machines. This may or may not be related, but is a piece of
possibly useful information. We are also running yp and NFS. (the problem is
not yp, even root could not login)
Has anyone else encoutered/have a fix for this problem?
We need help! I sent an Applelink about the problem to TECH.EAST and our
local reps, and am waiting for a response. Should I have sent the link
somewhere else? and Apple types are you listening?
If responding by email, please send to glenn@prism.gatech.edu since vail is
going to die for a little while.
Glenn Souther
Office of Computing Services
Georgia Insitute of Technology, Atlanta Georgia, 30332
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!glenn
INTERNET: glenn@prism.gatech.edu BITNET: CC100GS@GITNVE2
Ma Bell: (404) 894-6176john@unisoft.UUCP (John Sovereign) (02/17/89)
In article <7290@pyr.gatech.EDU> glenn@vail.gatech.edu (Glenn Souther) writes: >We have encountered a critical problem with our general access A/UX machines. >When attempting to login ON THE CONSOLE, after entering the account name, >A/UX responds with an incorrect login message, and again asks "login:" >After hearing that System V has this problem when a process has the console >other than the getty/login. So, I telneted into one of the machines and The toolboxdaemon is not a well-behaved daemon. It does not release its controlling terminal -- in this case, the console. (For information on the correct way to do this see Dave Lennert's classical treatment in the Dec. '88 issue of "UNIX World".) One "fix" which may work is to move the entry in /etc/inittab for the console getty before the entry for the toolboxdaemon, since init reads the inittab and performs its actions from the beginning. To give the getty as much time as possible to seize the controlling terminal, move its entry in front of all the "level 2" entries, i.e., before the errdemon and cron. You should also change the "action" fields for the errdemon and cron to "wait"; this will have the effect of synchronizing init. If the toolboxdaemon is still grabbing the console before the getty, move the toolboxdaemon entry farther down in /etc/inittab. One side effect of this change may be that initial console logins will fail because YP is not running yet (you may be observing this already); however, the symptom is slightly different -- you will be prompted for your password. Of course, the "real" fix is for getty to perform something like BSD's vhangup(), but perhaps not quite so fascist. :-> John Sovereign UniSoft Corporation {uunet,ucbvax,...}!unisoft!john P.S. There is another bug where the single-user shell is not the Bourne shell and another process has the console open before going multi-user. You could be hitting this if you've changed root's shell and the toolboxdaemon is being started in single-user mode.