Users Can't Login on the Console (tty01)
Bob Stockler
Problem: No user can log in on the console (tty01).
This just started recently, after a reboot following a kernel
panic. The Software Manager (custom) has no complaints after
verifying all software installed on the system.
All users can log in on tty02-tty12 and, root has no problem
logging into single user mode, but in multiuser mode . . .
At the initial "login:" prompt I must type each character of
the user name and the [Enter] key twice before the "Password:"
prompt appears.
After typing in the password I must press the [Enter] key two
times. I doesn't matter if I single or double strike the
characters in the password, I always get:
Login incorrect
Wait for login retry .
login: _
At this point it accepts single striking the characters in the
user name, but the "Password:" prompt never appears. I finally
get:
Login timed out
Wait for login exit:
after which the screen clears, the initial "login:" prompt
reappears, and the cycle repeats itself.
If I press [Enter] before seeing the "timed out" error message
I simply get another "login:" prompt. Entering the user name
at it evokes the same behavior as did the previous instance.
I verified for myself that 'getty' is accepting the user name
properly (whether entered with single or double key striking)
by executing this script while trying to login on tty01:
#!/bin/ksh
while :
do sleep 1 ; date ; ps -ef | grep console | grep -v ttyp4
done > /tmp/report
and seeing these (edited) results in the output file:
Sun Nov 12 09:46:26 EST 2006
root 10159 1 0 16:22:34 console 00:00:00 /etc/getty -n tty01 sc_m
Sun Nov 12 09:46:27 EST 2006
root 10159 1 0 16:22:34 console 00:00:00 /bin/login root
Sun Nov 12 09:47:29 EST 2006
root 19067 1 0 09:47:29 console 00:00:00 /etc/getty -n tty01 sc_m
Sun Nov 12 09:47:45 EST 2006
root 19067 1 0 09:47:29 console 00:00:00 /bin/login root
Sun Nov 12 09:48:46 EST 2006
root 19456 1 0 09:48:46 console 00:00:00 /etc/getty -n tty01 sc_m
The SCO Knowledge Base offered no help. Can YOU help?
Bob
--
Bob Stockler +-+ b...@trebor.iglou.com +-+ http://members.iglou.com/trebor
Nachman Yaakov Ziskind
Duplicate entries in /etc/inittab, maybe?
--
_________________________________________
Nachman Yaakov Ziskind, FSPA, LLM aw...@ziskind.us
Attorney and Counselor-at-Law http://ziskind.us
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants
Bill Campbell
> System: SCO OSR6 (MP1, OSS702a, OSS702b and MP2)
>
>Problem: No user can log in on the console (tty01).
>
>This just started recently, after a reboot following a kernel
>panic. The Software Manager (custom) has no complaints after
>verifying all software installed on the system.
>
>All users can log in on tty02-tty12 and, root has no problem
>logging into single user mode, but in multiuser mode . . .
I think you need to remove ``/etc/ioctl.syscon'' and reboot the system.
Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
It is necessary for the welfare of society that genius should be
privileged to utter sedition, to blaspheme, to outrage good taste, to
corrupt the youthful mind, and generally to scandalize one's uncles.
-- George Bernard Shaw
Bob Stockler
Thanks, Nachman, but no joy. Its only duplicated lines are
two lines consisting of only a #.
Bob Stockler
| On Sun, Nov 12, 2006, Bob Stockler wrote:
| > System: SCO OSR6 (MP1, OSS702a, OSS702b and MP2)
| >
| >Problem: No user can log in on the console (tty01).
| >
| >This just started recently, after a reboot following a kernel
| >panic. The Software Manager (custom) has no complaints after
| >verifying all software installed on the system.
| >
| >All users can log in on tty02-tty12 and, root has no problem
| >logging into single user mode, but in multiuser mode . . .
|
| I think you need to remove ``/etc/ioctl.syscon'' and reboot the system.
Thanks, Bill, but I'm going to think about trying that until
tomorrow. It's 5:32 EST here in Louisville, KY (and Sunday)
which is an hour or so into cocktail hour.
On my SCO OSR6 system, ``/etc/ioctl.syscon'' is a symlink to:
/var/opt/K/SCO/Unix/6.0.0Ni/etc/ioctl.syscon
And that latter file has a date-time stamp indicating it was
part of the original installation (which didn't fail the
check by custom, and worked until just recently).
Bob (who is now going back to get more gedunk and cocktails)
Bob Stockler
| On Sun, Nov 12, 2006, Bob Stockler wrote:
| > System: SCO OSR6 (MP1, OSS702a, OSS702b and MP2)
| >
| >Problem: No user can log in on the console (tty01).
| >
| >This just started recently, after a reboot following a kernel
| >panic. The Software Manager (custom) has no complaints after
| >verifying all software installed on the system.
| >
| >All users can log in on tty02-tty12 and, root has no problem
| >logging into single user mode, but in multiuser mode . . .
|
| I think you need to remove ``/etc/ioctl.syscon'' and reboot the system.
Thanks, Bill, but I'm going to think about trying that until
tomorrow. It's 5:32 EST here in Louisville, KY (and Sunday)
which is an hour or so into cocktail hour.
On my SCO OSR6 system, ``/etc/ioctl.syscon'' is a symlink to:
/var/opt/K/SCO/Unix/6.0.0Ni/etc/ioctl.syscon
And that latter file has a date-time stamp indicating it was
part of the original installation (which didn't fail the
check by custom, and worked until just recently).
Bob (who is now going back to get more gedunk and cocktails)
--
Bela Lubkin
That description sounds just like two processes are competing to consume
your input. Does OSR6 come with `lsof`? Login on a tty that does work
and run `lsof /dev/tty01`, what processes have it open? Compare to
output for another not-logged-in console tty that you know isn't having
the problem.
It's common for multiple device nodes to exist which access the same
tty. Again, I'm not that familiar with OSR6, but see if any other names
also mean "tty01". e.g. /dev/console, syscon, systty, vt00 or vt01,
etc. You can test by sitting at a root shell prompt on tty02 and doing:
echo checking syscon > /dev/syscon
etc. (only do this to names that already exist in /dev and that you have
at least some plausible reason to believe might be aliases for tty01).
Anyone, once you've done a series of those, then flip the display to
tty01 and see which ones showed up.
Now that you have a list of aliases for tty01, run `lsof` on them:
lsof /dev/tty01 /dev/console /dev/vt00 ...
You'll see at least one other process besides the expected `getty`. Now
figure out why it is running -- wrong entry in inittab? rc script gone
wild?
Once you've identified it, see what happens if you kill it. Does
something (probably `init`) start another copy? Then you know where to
look (inittab). Does it die and stay dead? Look for an rc script or
other non-repeating instruction.
>Bela<
Jean-Pierre Radley
attempts, including root's password, show up in a file on your machine.
Bela Lubkin typed (on Sun, Nov 12, 2006 at 03:22:43PM -0800):
--
JP
==> http://www.frappr.com/cusm <==
Bela Lubkin
Someone posing as Jean-Pierre Radley then wrote:
> Bob, waste no time following Bela's advice. All of your failed login
> attempts, including root's password, show up in a file on your machine.
What on earth are you talking about?
He's trying to solve a problem with bad input handling on tty01.
Whether failed logins are logged anywhere is totally irrelevant to that.
I also sincerely hope you are wrong about the (irrelevant) logging. It
is bad security policy to log failed passwords (you will catch typos of
the correct password, correct passwords from different systems, etc.)
It's even bad policy to log the login names that were attempted, except
when they correspond to real logins known to the system; otherwise you
will catch cases where the user mistakenly typed their password into the
login prompt.
I hope you will agree that logging anyone's passwords is a bad idea,
even if the original intent wasn't to log passwords. But -- assuming
for a moment that this is actually true, please elucidate. In what file
are the failed login & passwords logged?
Between the top-posting (reversed here) and the sharply stupid advice, I
can only believe that this is someone posing as JPR. Though they've
done a fairly good job of the headers other than top-posting...
>Bela<
Dan Martin
> Bill Campbell wrote (on Sun, Nov 12, 2006 at 01:23:18PM -0800):
>
> | On Sun, Nov 12, 2006, Bob Stockler wrote:
> | > System: SCO OSR6 (MP1, OSS702a, OSS702b and MP2)
> | >
> |
.
.
> Thanks, Bill, but I'm going to think about trying that until
> tomorrow. It's 5:32 EST here in Louisville, KY (and Sunday)
> which is an hour or so into cocktail hour.
>
5:32 EST and you're only an hour or so into cocktail hour?
On a Sunday?
Set aside the console problem, your immediate issue is
reconfiguring TZ!
Good luck,
Dan Martin
....
Bob Stockler
Situation resolved.
When upgrading from SCO OSR 5.0.6 to OSR 6, one of my
startup scripts (/etc/rc2.d/S99remprt) was no longer
useful, so it was deactivated by making these two lines
the first lines in that file:
#!/bin/sh
exit 0
Recently, when I was planning to change root's login
shell to be /bin/ksh I was advised that it might be wise
to see that all startup scripts had #!/bin/sh as their
first line. It must have been at that time when I edited
/etc/rc2.d/S99remprt I accidently changed its 1st line to
be: $!/bin/sh (changing the # to be $).
So, when starting up, this caused a shell to run on tty01,
because (I'm told) the /bin/sh executing the scripts saw
the $! as an argument where $! was the PID of the last
process ran in the background and therefore NUL, so the
shell just ran, attached to tty01.
The file that contained all of the info about my attempted
logins on tty01 was /etc/rc2.d/messages/S99remprt.log - an
unintentional logging (phishing) by me of mine.
Sherlock Holmes (aka Jean-Pierre Radley) got on my system
and did an 'lsof' and 'ps' and a little other investigating
disclosing the root of the problem (user error - I'll never
know how I accidently changed that # to a $).
Bob (who thanks all who responded to my plea for help)