SUMMARY/SOLUTION: I don't know what fixed the problem. I tried several
things included here with no success. One day last week, one of my users
came to me and said all of a sudden it worked. We have since submitted
paperwork to have this machine covered by a Sun software maintenance
contract (However, I think many people on this mailing list have just as
much or more knowledge and/or experience than Sun software engineers) I
appreciate the good ideas of places to check from Peter Wargo and Eddy
Sutanto (I've included their suggestions). I also found a summary with the
exact same problem while searching through the Sun Managers archives. I've
enclosed the steps taken to solve that problem as well. My original
question is at the end.
check in the .cde directory for the startlog and errorlog. Chances are
something has changed in the .cshrc, .login, .profile, or
.whatever to give CDE heartburn.
Also, just as an aside, have you uncommented the last line in .dtprofile?
-Peter L. Wargo | plw@ncgr.org | +1 505 995 4476
Senior Systems Administrator
The National Center for Genome Resources
Santa Fe, NM 87505 (USA) | http://www.ncgr.org
Have you tried the command line login? If that works you probably need
to re-install CDE.
Check the uses's .cshrc and .login file as well. I had come across once; an
entry of "setenv DISPLAY `uname -n`:0.0" did create a login problem.
What I did was comment out that line and added "xhost +" in the following
file: $HOME/.dt/sessions/sessionetc. The second option may or maynot
apply to your case, but just incase.
Eddy Sutanto Schlumberger GeoQuest - Indonesia
Hardware/System Engineer SENTRA MULIA, 17th Floor, Suite 1701
Ph: (62-21) 252-0372 Jl. H.R. Rasuna Said, Kav. x-6, No. 8
Fax: (62-21) 252-0375 Jakarta 12940 - Indonesia
=========================================================================
E-mail: sutantoe@jakarta.geoquest.slb.com
===============================================
SUMMARY: Users cannot login in CDE
From: Hernan Dario Russy Pena <hrussy@mox.uniandes.edu.co>
Reply-To: hrussy@mox.uniandes.edu.co
Subject: SUMMARY: Users cannot login in CDE
Date: Thu, 6 Nov 1997 16:29:50 -0500 (Eastern)
Symptoms and Resolutions article 13452
[ Notify of patch changes ]
[ Edit/Retrieve Marked Documents ] [ Mark Document ]
----------------------------------------------------------------------------
SRDB ID: 13452
SYNOPSIS: CDE login fails, returning you to the login screen
DETAIL DESCRIPTION:
At the CDE login (dtlogin) window, you have entered your username and password
correctly.
Dtlogin attempts to log you in (e.g., the background changes, a new
Xserver is started, etc.) but then, for no obvious reason, the login
fails.
You are then abruptly returned to the dtlogin window.
SOLUTION SUMMARY:
There are a number of problems that could be at fault here.
Follow through the steps ensure that each one isn't the cause.
1) Look at the startlog and errorlog files in $HOME/.dt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
They might give you clues to the cause of the error.
2) Some error in the global customization of CDE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Since CDE is so customizable, it is possible that something
that has been done to the global customization area has
confused the login.
The command rm -rf /etc/dt removes all the global
customization. Save the /etc/dt first if the changes are
important.
3) An error in the local customization of CDE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove everything in the directory $HOME/.dt and the file $HOME/.dtprofile
>From a command line login or remote telnet connection, move or remove
the directory $HOME/.dt and the file $HOME/.dtprofile.
These files or directories will be recreated on the user's next CDE login.
4) Some error in the users environment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is possible to put commands in the user's environment that
confuse the CDE login environment.
To prove that this is not the case, either remove or save the following
file depending on the users shell. If your not sure, do all of the
following:
cd $HOME
rm -f .login .cshrc .profile .kshrc
and remove any customization from /etc/profile that has been
added. The online manual pages for the various shells describe
what files are used during a login.
As an alternative, set up a local user on the host and try logging in as
that user. If it works, its a user issue, if it doesn't, its an
environment issue.
5) A Permissions or Access problem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After you have removed the customization that could have occurred
as described in the steps above. Attempt to login as the root user.
Since access there is unrestricted on any local file system it will
prove if the problem is a permissions problem or something else.
Because logging in as root only checks permissions on a local
file system, find out if the /usr/dt or /usr/openwin directories
are local file systems.
If these directories are NFS mounted from another machine, ensure
that they are mounted and shared with root access.
You can do this on Solaris 2.x with the command:
share -F nfs -o root=machine /usr/dt
Change the machine and the directory to export to be appropriate for your
environment. Refer to the online manual page for share_nfs for
further details.
6) Incorrect tooltalk daemon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the CDE installation failed to work which, although unlikely,
is a possibility, then the old OpenWindows tooltalk daemon
may still be used.
Check that the latest version is installed by looking at the
file /etc/inetd.conf and look for a line like that below:
100083/1 stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd
rpc.ttdbserverd
The important point is the path to /usr/dt/bin/rpc.ttdbserverd
7) Is or has the disk space reached 100 % in any partition?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In some circumstances if a file system reaches 100% full, the
tooltalk databases can get corrupted. The tooltalk databases,
which are located at each local mount point and are in directories
with the name TT_DB will need to be cleaned up.
Check the srdb 12729 - How to clean out the ToolTalk databases
for detailed information about how to achieve this.#
A similar effect can be seen if a users quota is exceeded.
8) What name service is being used?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Look at the file /etc/nsswitch.conf to see what name service
is being used. Look at the hosts line. If it is anything other
than
hosts: files
temporarily change that entry as above so that only the /etc/hosts
file is accessed when trying to lookup host information.
Ensure that in the /etc/hosts file there is an entry for localhost
as shown below and an entry for the machine name.
127.0.0.1 localhost
Double check that the IP address for the machine is the same as
the system IP address. Run the command:
ifconfig -a
to see what the interfaces IP addresses are defined as. Check that
the first name after the IP address for the machine is the same as
defined in /etc/hostname.* where * is the name of the interface.
After confirming the details, reboot the system to ensure all
processes take account of the temporary change of name service.
If the login works after that then there is a problem with the
previous's hosts map whether it be DNS, NIS or NIS+. Either
locate the specific problem or change the name service map
/etc/nsswitch.conf to have the files entry before the name service.
E.g. for a DNS name services the /etc/nsswitch.conf hosts line would
be:
hosts: files dns
9) Manually start CDE from the command line
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>From the command line (i.e., no gui is running), log in as
root and start the CDE environment using the commands
below (assumes the root shell is ksh or sh):
# OPENWINHOME=/usr/openwin
# export OPENWINHOME
# $OPENWINHOME/bin/xinit /usr/dt/bin/Xsession
If this fails, does a core dump get generated? Look at it via
the symbolic debugger "debugger" using a command such as:
debugger fullpath_of_program core
> where
> quit
If no core file is generated, try using the truss command to see if
you can identify the error. The command below will truss
the processes and store the truss output in a file in the current
directory called logfile:
# truss -aef -o logfile $OPENWINHOME/bin/xinit /usr/dt/bin/Xsession
10) Check that the hardware is supported?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Check that the model, framebuffer and disks are all supported
with CDE.
11) Re-Install CDE
~~~~~~~~~~~~~~~~~~
If you still can't solve the problem, re-install CDE from the CDROM.
The install-cde script will attempt to remove the previous installation
before installing the packages again.
12) Re-Install OS + CDE
~~~~~~~~~~~~~~~~~~~~~~~
Loring Safford wrote:
> SUN experts (much more so than I anyway),
>
> QUESTION: SUN SPARC 20 with Solaris 2.5 and CDE ver. 1.0
> Users have been connecting to CDE on this machine via PC's using XDM for the
> last couple of months with no problem. All of a sudden they get an open
> windows screen instead. They are able to telnet and get a shell, but cannot
> get to CDE.
>
> When I try to lgin from the console CDE screen it comes back with blank CDE
> login screen after I enter my userid and password.
>
> In the /var/dt/Xerrors file:
> error (pid 210): error binding socket address 177, errno =2
>
> I checked /opt/dt/config/Xconfig and /etc/dt/config/Xconfig for the * at the
> end to allow connections.
>
> I've stopped and started CDE and rebooted with no affect.
>
> Could somebody point me in the right direction please? I will summarize. I
> had a print problem some time back that isn't totally resolved. I'll
> summarize that as well when I get it totally fixed.
>
> Thanks,
>
> Loring Safford lsafford@mitretek.org
> Mitretek Systems - Z553 phone: (703)610-2818
> 7525 Colshire Drive fax: (703)610-1603
> McLean VA 22102-3481
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:38 CDT