Threat Report: Exposing Malware in Linux-Based Multi-Cloud Environments | Download Now

Remove Hanging Processes

Remove Hanging Processes


All Versions of Cb Response


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


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

cb-pgsql is dead but PID still exists


cb-rabbitmq is dead but subsys locked


  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/
  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
Labels (1)
Was this article helpful? Yes No
No ratings
Article Information
Creation Date: