Somebody . . . . Thanks!

[Robert White]

Ok, little things first:
	The XINX banner before login: is provided by gettys.  After
you type a string to gettys it execs login(1) with that information
so it is normal to loose the header info on unsuccessful attempts
to log in.  Second and subsequent "login:" messages come from the
login program directly.  Login does not possess builtin banners
as some versions of gettys do, nor does it read /etc/gettydefs for
the login prompt information.  You get the password wrong and login
just spews out "login:" in an attemtp to give you a second chance
without hanging up the phone.
	Similarly, login will kill itself and init will respawn gettys
if either too much times passes or to many unsuccessful login
attempts are gone through.  Typical stats are 2 min or 5 tries.
	gettys and login are run with root permissions.  When the identity
of the user has been established login looks up the starting shell
in the password file and writes that information into the utmp
file, changes it's real and effective user and group ids as
approprate and then execs the indicated program.  Normally
something like /bin/sh.
	The shell runs /etc/profile and then the users .profile and
then provides the normal prompt.  /etc/profile is not optional
but .profile is.

	Taking everything you say into account, the fact that the
symptoms are the same for the console and the terminals and that
you can log in a root, but nobody else says that whatever is going
wrong happens after the set-user-id phase of login.  Something that
needs *must* be accessable by the user is not.  My best guess would
be that you have replaced and/or copied over /etc/profile and that
it is no longer readable by others.  Or the shell itself is not
readable and executable by others, but that is a much less likely
possibility.  Since root can read everything the /etc/profile
and /bin/sh permissions problems are most likely, the obscurity
of the /etc/profile makes it a better canidate for overlooking.

	Chances are the login mechanisim is still in perfect working
order.  To check it, replace/fill-in the last entry of the password
file for a "normal user" with a command that is harmless and
produces definite input.  /bin/who should do nicely.  If the command
runs when you attempt to login then the problem has to do with
the shell.  If the command does not you should check /etc/passwd
or /etc/shadow (if your system supports it  maybe even pwunconv
and pwconv the file to recreate it) and whatever else is used
durring login.  Make shure you have room on you root file system
for the utmp and wtmp entries and check all the log files under
the login manual page to make shure they have been cleaned out
lately.  Running out of disk space, or even getting close can
mess up mundane things like shell pipelines and such, if any
of your filesystems (esp the root and pipe file system which
are usually the same thing) are nearly full you can get strange
behavior.

	Well, I am sick and I have free-associated long enough.
Hope my rambling helped.
-- 
Robert C. White Jr.          |  I have moved my news reading activities
rwhite at jagat           <Home |  not directly related to my job off of my
rwhite at nusdecs         <Work |  employers machine.  Please use "jagat"
"Like most endevors, life is seriously over-advertised and under-funded"