Remove Hanging Processes

[#1]

Version

All Versions of Cb Response

Cause

This is caused by a process being killed forcefully (kill -9). As a result it doesn’t have time to clean up after itself.

Symptoms

When running a status check you will see processes with messages such as:

cb-pgsql is dead but PID still exists

or

cb-rabbitmq is dead but subsys locked

Steps

1. Check for hanging processes:
   

   ps -ef | grep cb

2. Verify All services have been stopped
   

   Note: If this is a cluster, verify the cluster has been stopped first. If you are following this process for cb-rabbitmq, you will likely need to follow this guide: CB cluster will not start - RabbitMQ service out of sync in clustered environment 

   1. Pre 5.2
      

      service cb-enterprise status

   2. In 5.2, supervisord needs to be running to get a status check:
      

      service cb-supervisord start
      service cb-enterprise status
      service cb-supervisord stop

3. Kill all hanging processes owned by cb:
   

   Warning: Killing processes without stopping services first could cause data corruption

   killall -KILL -u cb

   Warning: This will also kill any cb integrations that run under the cb user. Please start these separately after running this command

4. Remove PID file(s):
   

   Warning: Removing PID or LOCK files without killing hanging processes will prevent services from starting correctly

   rm -f /var/run/cb/cb-<PROCESSNAME>.pid

   1. Rabbitmq pid is located differently (/ rather than .)
      

      rm -f /var/run/cb/rabbitmq/pid

   2. Psql also requires removing postmaster pid:
      

      rm -f /var/cb/data/pgsql/postmaster.pid

5. Remove LOCK file:
   

   rm -rf /var/lock/subsys/cb-<PROCESSNAME>

6. Start the service:
   

   service cb-enterprise start

7. Verify all services are running:
   

   service cb-enterprise status

8. Test Cb Response UI functionality