Hi sysadmins,
Thanks to everyone who responded:
"D. Ellen March" <emarch@pinole1.com>,
CHENTHIL KG <chenthil@mtcts1.mt.lucent.com>,
Nick Murray <nmurray@csd.abdn.ac.uk>
"Arora, Samir" <sarora@ELDEC.com>,
Jim McVey <jmcvey@nhgri.nih.gov>
Your answers were of great help. The solution was chmod'ing
644 /etc/mnttab
Original question:
We have the following system:
- SPARC 2xULTRA-2 / 296Mhz. 512 MB RAM
- Solaris 2.5.1 installed
- CDE 1.0.2 installed
- Patch 103882-05 installed
and the following problem:
- Users cannot login in CDE. Session almost starts and then the login
screen reappears.
Everything was fine just some days ago, but now only root is able to
login and normal users cannot (just in CDE, telnet and text login work
fine).
Any user's ~/.dt/errorlog looks like:
Thu Oct 30 12:57:29 1997
dtsession: Unable to start message server - exiting.
and startlog looks like:
--- Thu Oct 30 12:57:20 GMT 1997
--- /usr/dt/bin/Xsession starting...
--- Xsession started by dtlogin
--- sourcing /u/admin/bacosta/.dtprofile...
--- sourcing /etc/dt/config/Xsession.d/0010.dtpaths...
--- sourcing /etc/dt/config/Xsession.d/0015.sun.env...
--- sourcing /etc/dt/config/Xsession.d/0020.dtims...
--- sourcing /etc/dt/config/Xsession.d/0030.dttmpdir...
--- sourcing /etc/dt/config/Xsession.d/0040.xmbind...
--- sourcing /usr/dt/config/Xsession.d/0010.dtpaths...
--- sourcing /usr/dt/config/Xsession.d/0015.sun.env...
--- sourcing /usr/dt/config/Xsession.d/0020.dtims...
--- sourcing /usr/dt/config/Xsession.d/0030.dttmpdir...
--- sourcing /usr/dt/config/Xsession.d/0040.xmbind...
--- starting /usr/dt/bin/dthello &
--- starting /usr/dt/bin/dtsearchpath
--- starting /usr/dt/bin/dsdm &
--- starting /usr/dt/bin/dtappgather &
--- execing /usr/dt/bin/dtsession...
not sourcing /u/admin/bacosta/.login (see /u/admin/bacosta/.dtprofile)
Segmentation fault
X connection to :0.0 broken (explicit kill or server shutdown).^M
X connection to :0.0 broken (explicit kill or server shutdown).^M
Answers:
- "D. Ellen March" <emarch@pinole1.com>
This is just a thought, did any global environment variable
change, specifically, the LD_LIBRARY_PATH?
Make sure the libs in /usr/dt are before any other ones.
- CHENTHIL KG <chenthil@mtcts1.mt.lucent.com>
All the users in their home directory,will have a .dtprofile file.Open
that & the last line should contain this
DTSOURCEPROFILE=true
Actually U just need to hash it out..U'll be all set..
- Nick Murray <nmurray@csd.abdn.ac.uk>
Check the permissions on /etc/mnttab. If it isn't globally readable I've
seen a similar effect.
- "Arora, Samir" <sarora@ELDEC.com>
Check your .login file for LD_LIBRARY_PATH and other paths.Also check
.cshrc
and .xinitrc file in your area.I believe some other version of Motif
libraries are there in your path environment Variables.
TO check that try login in openwindows mode.See if that works
- Jim McVey <jmcvey@nhgri.nih.gov>
I had the same problem a couple of months ago. I got the following doc from
Sun wheich helped me track down my problem. (Using method #9 (truss) I
discovered I had incorrect permissions on /etc/mnttab.)
Good luck.
Jim
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
~~~~~~~~~~~~~~~~~~~~~~~
After this time, it shows that that must be some change to the
system that is extremely difficult to track down. It is probably
simpler to just re-install the OS and CDE from scratch.
Re-install the OS starting with a simple configuration with
no networking.
Check that CDE works and then add networking and any
name service that is required until either the problem re-appears
or the system is fully functional again.
PRODUCT AREA: Windows
PRODUCT: CDE
SUNOS RELEASE: Solaris 2.x
HARDWARE: any
----------------------
Hernan Dario Russy Pena
hrussy@mox.uniandes.edu.co
Universidad de Los Andes
Bogota, COLOMBIA
Tel: (571) 2869211 Ext. 814, 2918
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:08 CDT