I'm trying to start the CCX Notification service in our secondary CCX server so agents can log in when the primary CCX is down, but it seems that service won't start at all, tried that by using the CLI and GUI, it shows INITIALIZING and goes back to shutdown state again
a screenshot can be found in the attachments section
Thanks a lot
Do you happen to know if this was happening from the start and the exact version of UCCX that you are running on?
A few reasons can block this from starting up:
- UCCX 10.x onwards, requires domain name to be set on the UCCX nodes. In the event of an upgrade from a previous release of UCCX (9.x and below), where the domain was not mandatory (well, to be honest, it wasn't documented, but if you remember all the problems on the CAD Desktop Services not starting up at the Desktop, that was the reason), you would end up with this problem. I assume that the domain has been set at the platform level for the publisher which is why your service for Openfire aka Cisco Unified CCX Notification Service can start up.
You can verify this real quick by running the command show network domain on both the nodes. This has been documented as an internal defect, but since there's no fix as the domain is mandatory for UCCX 10.0 and onwards, the resolution of the defect is inclusion into the documentation to make it mandatory.
If it's not been set on the secondary node, then you can set it via set network domain and reboot the secondary node.
- Another common issue for the service to get affected would be the CPU utilization. The platform command show process load should provide you with sufficient diagnostic information on the process that's utilizing most CPU and memory information. You can check to see if finesse_start or openfire process is hogging either of those.
A common place to check would also be the OVA template that was used to build the secondary. Was this built in the same way as that of the publisher by downloading the OVA from cisco.com and then applying the image onto the Virtual Machine? A good way of verifying this (thanks to the platform) would be checking if you see the message PARTITIONS ALIGNED on the CLI bash shell when you login. We enhanced the platform to throw an error here if we do not meet the OVA specifications.
- Snapshots - A common reason which hides behind major application problems and creepily affects the performance. Snapshots alter the VMDK architecture in the backend and especially with UCCX and CUCM can lead to a variety of issues at the application level.
- What does the System Info API provide? You can run the API with the following URL:
This should show the details of the domain that the Openfire service uses, since it picks it up from the platformConfig file which is updated when you perform the actions from the first bullet point.
Let me know if this helps!