SUMMARY: rpc.ttdbserver problems

From: Rich Moseng (moseng@ssec.honeywell.com)
Date: Fri Jun 27 1997 - 09:46:21 CDT


Wow, thanks for the quick and helpful response to solve my problem!
(This list is great!!) I'd like to especially thank the following
3 people who pointed me in the right direction:

   Davin Milun
   Miriam von Zuben
   Hans Schaechl
      
The problem turned out to be a corrupt database in the directory /TT_DB
The solution was to stop the daemon, clear the database, and restart the
daemon. (The original question is at the end of this message. And here
is the solution):

SOLUTION SUMMARY:

The procedure to clean out the databases is as follows:

1) Stop the ToolTalk daemon.

   Comment out the line in /etc/inetd.conf so that it looks like:

        #100083/1 stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd \
           /usr/dt/bin/rpc.tt dbserverd

   and refresh inetd with the command:
        kill -1 1

   Find the process ID of the currently running daemon:
        ps -e | grep rpc.ttdb

   and kill it with
        kill [pid]

2) Delete all ToolTalk Databases on the system.

   For EACH and EVERY local file system, type
        rm -f [mount_pt]/TT_DB/*
        
   It is very important to get ALL the Tootalk databases. The local
   mount-points may be found with the command:
        df -Fufs

   (Don't worry if some of these don't contain a TT_DB directory.)

3) Restart the daemon:
   Uncomment the line in inetd.conf again, and type
        kill -1 1

>Hello list,
>
>I have a Sparc 10, running Solaris 2.5.1 and it frequently has
>the following problem. After a week or so of being 'up', the
>rpc.ttdbserver starts going wild and taking up all of the cpu time.
>
>top on 'problem workstation'...
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> 554 root -15 0 2824K 1340K run 168.3H 75.55% 82.71% rpc.ttdbserver
>
>top on 'regular workstation'...
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> 386 root 25 0 2888K 868K sleep 0:06 0.00% 0.00% rpc.ttdbserver
>
>
>This slows the machine down to almost a crawl and the user starts
>to whine (surprise, surprise). A reboot fixes the problem, but only for
>about a week, then it comes back.
>
>
>Any ideas?
>
> Rich

--

+---------------------------------------------------------------+ | | | Richard D. Moseng, Jr. Honeywell Inc. | | System Administrator Solid State Electronics Center | | Phone: (612) 954-2079 MN14-3C15 | | Fax: (612) 954-2742 12001 State Highway 55 | | Plymouth, MN 55441-4799 | | | +---------------------------------------------------------------+ Email: moseng@ssec.honeywell.com

--



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:58 CDT