Well it may work better but its not exactly solved, is it.
What I would do is to truss(1M) a login session .
Logon to the root account from another PC using SSH or telnet or
whatever .
Find the dtlogin deamon for the VGA screen, process 646 in the example
below.
process 617 is the overall dtlogin daemon.
# ps -ef | grep dtlogin
root 646 617 0 15:31:34 ? 0:00 /usr/dt/bin/dtlogin -daemon
-udpPort 0
root 617 1 0 15:31:29 ? 0:00 /usr/dt/bin/dtlogin -daemon
-udpPort 0
Start a truss session:
# truss -rall -wall -vall -sall -fao /var/tmp/truss_trace -p 646 &
Now switch to the PC VGA screen of the sick PC.
login graphically as "anyuser " and logout.
now the file /var/tmp/truss_trace should contain quiet a few megabytes.
find the line that contains "exec /usr/bin/login "
a few lines further down you should see a "fork" and a new
PID_number at the
start of the line . Then do
grep PID_number truss_trace > login_trace
The problem should hopefully be visible in the file login_trace.
the login binary is supposed to read the home directory from the
/etc/passwd file
we can do
grep open login_trace
to find the files that is opened by the login program
open the login_trace in an editor or with less(1)
scroll down to were it opens the passwd file
What happends next ?
//Lars
This message posted from opensolaris.org
_______________________________________________
opensolaris-help mailing list
[email protected]
