topic Re: System Crash - Tooltalk error? in Operating System - HP-UX

System Crash - Tooltalk error?

Jim Adamson — Wed, 13 Mar 2002 10:13:03 GMT

Hi,
I am trying to investigate a problem with a HP J5000 workstation running hpux10.20. This host abruptly rebooted yesterday - it most have been a non-graceful shutdown as fsck ran when the machine rebooted. It was almost like a power outage but no other machine in the room was effected.

The OLDsyslog shows a number of ToolTalk error messages running up to the reboot. The current syslog shows similar messages after the reboot. The messages are -

Mar 12 13:45:18 goss syslog: libtt[5319]: ttdt_Xt_input_handler(): tttk_message_receive(): TT_ERR_NOMP^INo ttsession process is running, probably because tt_open() has not been called yet. If this code is returned from tt_open() it means ttsession could not be started, which generally means ToolTalk is not installed on this system.

I'm not too sure what ToolTalk does and if this is enough to bring down the host. There are various core dumps under /var/adm/crash but I'm not too sure what I should be looking for.

I have done 'rpcinfo -p host' and ttdbserver is running on port 2517.

So any pointers would be welcome
thanks,
Jim

Re: System Crash - Tooltalk error?

Alex Glennie — Wed, 13 Mar 2002 10:20:14 GMT

what's your patch level wrt cde there was a problem wrt ttdbserver and high cpu some time ago .... I'd advise installing the latest CDE patch ?

Also it would be better to try and catch the system in the act ie set up some form of monitoring if this is a regular event but the following may be of use if relevant (I'm assumming this is a toolyalk related problem which it might not be) :

CDE (Common Desktop Environment) uses the rpc.ttdbserver daemon to
facilitate loading of the ToolTalk databases when users login to the
desktop. It is mainly used to connect to the Desktop of other CDE
systems to exchange data from the Calendar Manager to Dtmail, or
vice versa.

The following situations could cause the high CPU usage:
Users' home directories mounted from an Auspex server containing
an incompatible rpc.ttdbserver daemon
Corrupt ToolTalk database files
ttdbserver entries in /var/adm/inetd.sec

The following information can be used to correct this problem.

I. Disable the process if you are not using CDE, or if you are not
exchanging ToolTalk data between other CDE systems:

A. Comment out the following line in /etc/inetd.conf:

rpc stream tcp swait root /usr/dt/bin/rpc.ttdbserver [......]

B. Execute the inetd -c command.

Note: The internet daemon should kill the currently running
rpc.ttdbserver. If not, manually kill the process.

--OR--

II. If users' home directories are mounted from an Auspex server:

A. Disable the rpc.ttdbserver process on the HP-UX system
(if it is not needed).

--OR--

Disable the process on the Auspex system (if it is not needed).

B. Update the version of the rpc.ttdbserver daemon on the Auspex.
Older versions have been known to cause conflicts with HP-UX
systems running CDE and ToolTalk.

C. Check to ensure that there are no ttdbserver entries in the
/var/adm/inetd.sec file.

If so, then remove these entries. These entries cause high CPU
usage.

The ToolTalk database/naming service (ttdbserver) relies on a special,
undocumented inetd state called "swait". "swait" is specified in the
inetd.conf file. This state is not subject to the usual HP security
filechecks. System administrators should not place entries referring to
the ttdbserver service in the /var/adm/inetd.sec file. The
system will ignore all such entries.

--AND--

III. Finally, attempt to correct the problem in the following manner:

A. Have all users log out of CDE.

B. Login (command line) as root and go to run level 2 (init 2).

C. Determine if rpc.ttdbserver is running.

Note: Kill rpc.ttdbserver (if it is still running).

D. Use the following code to remove all TT_DB database files:

for i in `df -Fufs | awk '{print $1}'`
do
# Remove all files under each TT_DB subdirectory found
# under each local file system mount point. It doesn't
# matter if one of the mount points does not have a
# TT_DB subdirectory, since the 'rm -f' will not produce
# an error.
rm -f $i/TT_DB/*
done

E. Go back to the previous run level.

Note: CDE will start again.

Re: System Crash - Tooltalk error?

K.Vijayaragavan. — Wed, 13 Mar 2002 10:21:21 GMT

See the log files,

/var/adm/syslog.syslog.log
/etc/rc.log
/var/adm/messages
/var/dt/Xerrors

See the ecommand output of

1)dr_dt
2)dmesg
3)bdf

-K.Vijay

Re: System Crash - Tooltalk error?

melvyn burnard — Wed, 13 Mar 2002 10:23:14 GMT

If the system has crashed, what does the INDEX file say under /var/adm/crash/ ?
This may nbot be related to ToolTalk at all.

Re: System Crash - Tooltalk error?

Jim Adamson — Wed, 13 Mar 2002 16:54:58 GMT

Thanks for your replies. I installed a few CDE and Motif patches - also I found an error in our dns tables from yesterday morning. Thats everything sorted now with no tooltalk errors in syslog.

thanks,
Jim