Version
Carbon Black Enterprise Response 5.1.0 patch 3 and below.
Issue
The Enterprise daemon stops RabbitMQ communication if we lose the RabbitMQ socket and does not re-establish communication.
Symptoms
The issue can manifest itself in a couple of ways:
- The update_timestamp column of the alliance_feeds table in the PostgreSQL database does not update until the services are restarted.
- Notifications (Syslog and Emails) features for watchlist/alliance feeds stop sending messages.
Cause
Feed synchronization and notifications are triggered by RabbitMQ events. If RabbitMQ is down, there will be no feed updates and/or notifications (for Watchlists and/or feeds).To identify this issue, run the below command on your CB Enterprise Response server:
/usr/share/cb/cbrabbitmqctl report | grep cmd.feed.synchronize
If nothing is returned, either upgrade to 5.1.1 patch 1 or contact Technical Support. If RabbitMQ is working as designed, the above command will print output similar to:
api.events exchange amq.gen-z3N_e16sEsIdJg1ZxSm31g queue cmd.feed.synchronize []
Solution
The fix improves on exception handling around the RabbitMQ listener so that if a socket exception happens, the Enterprise daemon does not throw out the thread. Instead, we allow the standard reconnect logic to run through and reconnect RabbitMQ communications when they are available.
- The issue will be resolved in CB Enterprise Response 5.1.1 GA (vanilla).
- A hotfix based on CB Enterprise Response 5.1.0 patch 3 is also available. Please contact Technical Support for installation instructions.
Important Note(s)
- Issue is tracked by defect CB-8216.
Internal Note
Internal Note [Feeds out of date and notifications (syslog, email) are not sending]
