help! solaris installation problem: DT messaging system could not be started.

when install solaris8 on ultra60, the following message appeared:
The DT messaging system could not be started.

To correct the problem:

1.Choose [OK] to return to the login screen.

2.Select Failsafe Session from the login screen's option menu and log in.

3.Check to see that the hostname is correct in these locations:


For additional information,see the DT User's Guide.
when the machine rebooted, RPC timed out appeared. when first CDE login, dump a core and could not log in normally, my machine is in a NIS+ domain, and mount two directorys from the server. how can i resolve this problem?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Have a look at the following doc from Sunsolve see if it can solve your problem. (if not, please try: /usr/bin/nisls
to see if you can see all the nis+ database, and try to run nisping. If you still have problem, please post a comment and your /etc/nsswitch.conf file, if you have problem with NIS+ client, such as NIS+ cache problem, I'll try to give you a hand.):

Here's the doc:
48687   Error message: DT messaging system could not be started   19 Dec 2002

Problem Description Top

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:    
    For additional information, see the DT User's Guide.

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

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
 pyro loghost

    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 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
           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

        # 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 the following 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

    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


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, or something 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
            # 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

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


Good luck!



Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I had this same problem.  One suggestion...go to and download the CDE patches.

Login via a telnet session (since CDE is not working) and install the patches.

No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:

PAQ  No refund

Please leave any comments here within the next four days.


EE Cleanup Volunteer
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.