880，solaris8，图形界面按任何东西都报错

popol

880，solaris8，图形界面按任何东西都报错

什么原因啊

风之幻想

遇到过,上回不能重新启动机器.所以,没有做什么实质性的操作.只是用xclock锁定屏幕了. 看了这个,你再看看也许有帮助.
Document ID: ID48687
Synopsis: Error message: DT messaging system could not be started (tooltalk)

--------------------------------------------------------------------------------

Problem Statement Top

"DT messaging system" is another way to describe tooltalk and its components
(ttsession, rpc.ttdbserverd, etc.)

This document provides possible solutions and things to check pertaining to
the following error message:

The DT messaging system could not be started.
To correct the problem:
Choose [OK] to return to the login screen.
Select Failsafe Session from the login screen's option menu and log in.
Check to see that the hostname is correct in these locations:
/etc/src.sh
/etc/hosts
/usr/adm/inetd.sec
For additional information, see the DT User's Guide.
<OK>

This particular problem will show up when the ttsession on the local system
cannot communicate with rpc.ttdbserverd on the homedir server. This can occur
for a variety of reasons. Following are things to check to resolve this
problem.




======================================================================
1. /etc/nsswitch.conf file
Check to ensure that the hosts line in the nsswitch.conf file reads
files first, then any of the name lookup services such as dns, or nis.
Examples of how this line should look:

hosts: files [NOTFOUND=continue]xfn nis
hosts: files dns
hosts: files nis

======================================================================
2. /etc/hosts

There are a variety of things to check concerning this file.

A. Ensure that the system name is the second uncommented entry in this
file. In the following example, pyro is the system in question

#
# Internet host table
#
127.0.0.1 localhost
129.147.128.147 pyro loghost
129.147.128.149 combie
129.147.128.166 pulaski


B. Verify that the loopback interface is the first entry and that it
does not contain other information, such as an alias for the loghost.

C. Verify that the /etc/hosts file is linked to /etc/inet/hosts

lrwxrwxrwx 1 root root 12 Mar 1 2001 hosts -> ./inet/hosts

D. Check for the correctness of the hostname

E. Check for the presence of a line file:hosts If this line exists,
comment it out.

======================================================================
3. rpcbind

Items to check concerning rpcbind include:

A. Check to see if rpcbind is running by:
ps -ef | grep rpcbind

If it is not running, start with the command:
# /usr/sbin/rpcbind

If rpcbind wasn't running, check:
- is the S71rpc script in rc2.d?
- is this script correctly named? (S instead of s)
- check permissions


B. Ensure the rpc daemon is running.
1. Type the following command to check whether the rpcbind
daemon is running.
# /usr/bin/rpcinfo -u localhost rpcbind
program 100000 version 1 ready and waiting
program 100000 version 2 ready and waiting
program 100000 version 3 ready and waiting

2. If the server is running, it prints a list of program and version
numbers that are associated with the UDP protocol. If rpcbind
seems to be hung, either reboot the server or follow the steps
from docs.sun.com on "How to Warm-Start rpcbind".

How to Warm-Start rpcbind
If the NFS server cannot be rebooted because of work in progress,
you can restart rpcbind without having to restart all of the
services that use RPC. Just complete a warm start as described in
this procedure.

1. Become superuser or assume an equivalent role.

2. Determine the PID for rpcbind.
Run ps to get the PID, which is the value in the second column.

# ps -ef |grep rpcbind
root 115 1 0 May 31 ? 0:14 /usr/sbin/rpcbind
root 13000 6944 0 11:11:15 pts/3 0:00 grep rpcbind


3. Send a SIGTERM signal to the rpcbind process.
In this example, term is the signal that is to be sent and
115 is the PID for the program (see the kill(1) man page).
This command causes rpcbind to create a list of the current
registered services in /tmp/portmap.file and /tmp/rpcbind.file.

# kill -s term 115

-------------------------------------------------------------------------------
Note : If you do not kill the rpcbind process with the -s term option, you cannot
complete a warm start of rpcbind and must reboot the server to restore service.
--------------------------------------------------------------------------------

4. Restart rpcbind.

Warm-restart the command so that the files that were created by the kill command
are consulted, and the process resumes without requiring a restart of all of the
RPC services. See the rpcbind(1M) man page.

# /usr/sbin/rpcbind -w
______________________________.


C. Check for the existence of /usr/sbin/rpcbind. Restore from backup.
If this doesn't exist, do a pkgchk on SUNWcsu to ensure other items
are not missing either. If there are other errors, it may be easiest
to reload the OS.

D. Has software been added, or have other changes been made which blocks
the port for rpc. Look at the inetd.conf file for a conflict.

======================================================================
4. Tooltalk

Items to check involving tooltalk include:

A. Is ttsession running? To check run the command:
# ps -ef | grep rpc.ttdbserverd

If it is not running, you can manually start it by running the command:
# /usr/dt/bin/rpc.ttdbserverd

B. Clean out the tooltalk database per Info doc 12729,
Cleaning out the Tooltalk Database.

C. Check the inetd.conf file for the tooltalk entry. It should look like
this:
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd


D. Check links for ttsession. When you run the command:
ls -l /usr/dt/bin

You should see the following links to /usr/openwin/bin:
- rpc.ttdbserverd
- rpc.ttdbserver
- ttsession

To correct these attributes, you can run the command:
pkgchk -f SUNWtltk


E. Check permissions on:
- /usr/dt/bin/ttsession
- /usr/openwin/bin/ttsession

F. Check tooltalk package by running the command:
# pkgchk SUNWtltk

G. Checksum of ttsession:
# sum /usr/dt/bin/rpc.ttserverd


======================================================================
5. File system full

Check all partitions to see if there are any full file systems,
particularly root, and the file systems where home directory
resides

# df -k

If any are at, or near 100%, reduce in size and then clean the tooltalk
database per info doc 12729.

======================================================================
6. Quotas


Verify that user's disk quota has not been exceeded by running the
following command:
#quota -v <username>

Also, you can check /var/adm/messages. After correcting the quota
problem, be sure to clean the tooltalk database per info doc 12729.

======================================================================

7. Check for consistency and correctness of hostname and IP address
throughout system files.

A. Check thefollowing files for hostname consistency:
- /etc/hosts
- /etc/nodename
- /etc/hostname.<interface>
- /etc/net/ticlts/hosts
- /etc/net/ticots/hosts
- /etc/net/ticotsord/hosts

B. Check the following files for IP address correctness
- /etc/hosts
- /etc/netmasks
- /etc/defaultrouter

C. Double check that the IP address for the machine is the same as
the system IP address. Run: ifconfig -a to see what 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

======================================================================
8. $HOME/.TTauthority file

Check the permissions and ownership.

Try moving this file and let it get re-created. This file is created
for each session and is unique to that session. If it does not exist
it will get recreated. This file is used to authenticate processes
that use your CDE session (Example: tooltalk, dtmail).

======================================================================
9. Check permissions on files in the $HOME/.dt directory

Check the permissions and ownership on files in the $HOME/.dt
directory against a system where there is not a problem.

======================================================================
10. Check ownership of home directory

Check the ownership on the home directory of the user who is
experiencing the problem.

======================================================================
11. Do pkgchk on the following packages:
- SUNWtltk
- SUNWxwplt
- SUNWdtdte
- SUNWdtwm
- SUNWdtlog
======================================================================
12. Ensure up-to-date on the following patches:
- tooltalk patch
- Xsun patch
- dtwm patch
- dtlogin patch
- dtsession patch
- motif
- framebuffer patch (to check framebuffer type: prtconf -F)


======================================================================
13. Network configuration

Any network configuration problems will usually result in dtlogin
problems.

A. NIS
- If NIS, ensure that system has been added to NIS maps
- Check other NIS setup

B. DNS
- Reverse lookup failure
- DNS entry did not match system entry
- Check entry in the ptr.XXX.dbfile under named. This can cause
erratic reverse lookups.
- Verify other DNS setup

C. DHCP setup
- Verify setup

D. Run sys-unconfig if you think the CDE problem has to do with
resolving the hostname. Then add information back in until problem
recurs.

======================================================================

Other things to try/look at:

A. Check the following files for error messages
- /var/dt/Xerrors
- /var/adm/messages
- $HOME/.dt/errorlog
- $HOME/.dt/startlog

B. Check for errors in the global customization of CDE:
- mv /etc/dt /etc/old.dt

C. Check for errors in the local customization of CDE. The following
files will be recreated when the user logs into CDE again.
- mv $HOME/.dt $HOME/old.dt

- mv $HOME/.dtprofile $HOME/old.dtprofile

D. Since it is possible to put commands in user's environment that
confuse the CDE login process, these files should also be checked.
Move the following files:
- mv $HOME/.login $HOME/old.login
- mv $HOME/.cshrc $HOME/old.cshrc
- mv $HOME/.profile $HOME/old.profile
- mv $HOME/.kshrc $HOME/old.kshrc

E. After removing customization, attempt to login in as root. Since
access there is unrestricted on any local file system it will prove
if the problem is permissions, orsomething else. Because logging in
as root only checks root permissions on a local file system, find
out if the /usr/dt or /usr/openwin directories are local file
systems. If these are NFS mounted from another machine, ensure that
they are mounted and shared with root access. On Solaris 2.x can do
this with command:
share -F nfs -o root=<system> /usr/dt

Change the machine and directory to export to be appropriate for
your environment. Refer to man page for share_nfs for more information.


F. Check to see if you get this error message if you manually start
CDE from the command line? Log in as root from command line using
commands:
# OPENWINHOME=/usr/openwin #export OPENWINHOME
# $OPENWINHOME/bin/xinit /usr/dt/bin/Xsession

If this fails, is there a core dump? Look at it via the symbolic
"debugger" using a command such as:

# debugger <full path_of_program> core > where > quit

If no core generated, try truss:
# truss -aef -l logfile $OPENWINHOME/bin/xinit
/usr/dt/bin/Xsession

G. Try creating a new user and see if that user can log in.
# /usr/sbin/useradd -m -d /testuser
# passwd testuser

[ 本帖最后由 风之幻想 于 2007-8-28 15:38 编辑 ]

popol

谢谢