Debugging the dblogd Process

Overview

When files on the volumes are not properly reflected in the Xinet Database (or in the Portal), you need to check if there is no backlog for the dblogd process. This article explains how to troubleshoot issues happening to this process.

Process

1. Confirm if there is a backlog of webdblog_nnn files by checking in the Xinet Server for one or more of these log files:
   1. Go to /var/adm/appletalk.
   2. Check for any files like webdblog_nnn (e.g., webdblog_001, webdblog_002, etc).
      
      
2. If there is only one webdblog file, event processing should be up-to-date. If there is more than one, you should verify if the dblogd process (the database daemon) is running:
   1. In the Xinet Administration view, go to the Database->Admin->Settings tab. This will report the current state of dblogd, either Running or Stopped.
      
      
      
   2. If it is stopped, you can click on the Restart Daemon button to start the dblogd process.
      
3. If restarting the daemon did not fix the problem, as the dblogd process is still not processing the backlog, we have to put the daemon in debug mode to collect detailed log information for further investigation:
   1. Stop the daemon if it is running: 

      /usr/etc/venture/bin/dblogd -k

   2. Next, verify that it has stopped by checking the currently active processes. The dblogd process should not be running.
      

      ps -ef | grep dblogd

   3. Restart the daemon, this time in debug mode, sending the output to the file /tmp/dblogd.out.
      

      /usr/etc/venture/bin/dblogd -D >& /tmp/dblogd.out

   4. Reproduce the problem (or simply let the daemon die if that happens to be the issue).
   5. Stop the debugging process by repeating the command:

      /usr/etc/venture/bin/dblogd -k

   6. Finally, restart dblogd normally by using the Database->Admin-> Settings tab and the Restart Daemon button (as in the step 2b).
   7. Review the output file dblogd.out for specific messages and warnings on what is the actual problem.