rpc.ttdbserver occupies 100% CPU time.

[Hai Nguyen_1]

Hi Folks,

I applied the Sep. 2001 patch bundle yesterday.
After that, I connected to the server's CDE (running HP-UX 11.00) using EXCEED. I believed that the rpc.ttdbserver was spawn on my connection and it consumed the whole CPU.
I attach a portion of the "top" output.
Please let me know if you know of any issue with ths process. Also, I believe that this process was not updated by my patching.
Thanks.

Hai

[Alex Glennie]

The calls in inetd.conf on 10.20 and 11.0 differ !!!
call in inetd.conf 10.20
rpc stream tcp swait root /usr/dt/bin/rpc.ttdbserver 100083 1 /usr/dt/bin/rpc.ttdbserver

call in inetd.conf 11.0
rpc xti tcp swait root /usr/dt/bin/rpc.ttdbserver 100083 1 /usr/dt/bin/rpc.ttdbserver

Check yours and correct it I'm 99.9 % certain that'll be your problem.

[Hai Nguyen_1]

Alex,

Thanks for your help. Unfortunately, the setting in my /etc/inetd.conf is exactly the same as yours for HP-UX 11.00. And before I patched the system yesterday, I had not seen this problem.

By the way, I have just located a patch PHSS_23800 in QPK1100, Sep 2001
which contains CDE fixes was loaded on my system yesterday. This patch has been superseded by PHSS_25138 which addresses a problem with rpc.ttdbserverd (buffer overflow in rpc.ttdbserverd causes core dump.)
I may try this patch to see if it fixes the problem.

Hai

[Alex Glennie · Accepted solution]

The patch is a good idea .... looks like I got the 0.1 % again ;)

fyi :

The "rpc.ttdbserver" daemon is used by CDE (Common Desktop Environment) 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 Calender Manager to Dtmail or vis-versa.

There are a number of things that can cause the high cpu usage. For example, users' home directories
mounted from an Auspex server containing an imcompatible rpc.ttdbserver daemon, corrupt ToolTalk
database files, ttdbserver entries in /var/adm/inetd.sec, etc. The following are some methods to correct
this problem. If these methods do not work or are not suitable for your circumstances then you should open a
call with our Software Support Center.

1.If you are not using CDE or not exchanging ToolTalk data between other CDE systems, then you can
simply disable this process by doing the following:

edit /etc/inetd.conf, commenting out the line:
rpc stream tcp swait root /usr/dt/bin/rpc.ttdbserver [......]
Then execute "inetd -c". The internet daemon should kill the currently running "rpc.ttdbserver". If
not, kill it manually.

2.If users home directories are mounted from an Auspex server you can do one of the following:

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.
Update the version of the rpc.ttdbserver daemon on the Auspex, since older versions have
been known to cause conflicts with HP-UX systems running CDE and tooltalk.

3.Check to ensure that there are no entries in /var/adm/inetd.sec for ttdbserver. If so remove
these entries, since this will cause high cpu usage.
The tooltalk database/naming service ttdbserver relies on a special undocumented inetd state called
swait, which is specified in the inetd.conf file. This state is not subject to the usual HP security file
checks. System administrators should not place entries referring to the ttdbserver service in the
/var/adm/inetd.sec file because they will be ignored.

4.Finally you can attempt to correct the problem by doing the following:
Have all users log out of CDE. Login (command line) as root and go to run level 2 (init 2).
Check if rpc.ttdbserver is running, and if so kill it.
Remove all TT_DB database files using the following:


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


Change back to the previous run level and CDE will start back up.

[Hai Nguyen_1]

Alex,

Thanks for your rich solution sets on rpc.ttdbserver. I have applied your solution 1 to my system since I launch only HP CDE using EXCEED running on PC. I meant that I commented out the entry rpc.ttdbserver in /etc/inetd.conf.

The CPU issue has gone by now. But I still wonder why it had not happened until I applied the Support Plus bundle, Sep. 2001. Can you explain? Thanks anyway.

Regards,
Hai

[Robin Sharpe]

Hi guys,

We are seeing the same problem on several of our systems, all 11.00. I am goint to try commenting out the inet.d entry as well, since we do not use tool talk.

Robin Sharpe
Berlex labs

[Dario_15]

Hi all,

i've seen the problem is the same on Solaris too. To solve the problem at the first time onto my HP-UX system i've applied a solution found in a SUN forum, written for Solaris. The procedure was the same posted here by Mr. Glennie.

c ya

Dario