Zenoss runs many processes in a default installation. Additional processes may be run depending on what ZenPacks are installed. Through a combination of the DAEMONS_TXT_ONLY and daemons.txt files, the running processes can be managed to include only processes required for the features you're using.
Zenoss Startup Dependencies
For starting up Zenoss, zeneventserver must start first, followed by zenhub. The rest of the Zenoss daemons can start in parallel after zenhub has started. This may allow us to optimize the start time in future versions of Zenoss.
Oftentimes ZenPack developers want to run as few processes as necessary to test the ZenPack on which they're working. Additionally, they need to know when processes need to be restarted when they've changed code in their ZenPack. This section deals with issues like these that affect ZenPack developers. It's also useful for those looking for a deeper understanding of how Zenoss works.
When you need to restart a given process depends on where it falls in the following classification of processes.
Java daemons never need to be restarted while developing ZenPacks. You can leave them running in the background through any changes you make.
- zeneventserver (must be running to install or remove ZenPacks)
- zencatalogservice (only in ZSD >= 4.2)
Daemons that don’t fit into any other category. Never need to be restarted during ZenPack development.
- zenrrdcached (not necessary on development systems)
Zope clients are the daemons that most often need to be restarted during ZenPack development. Anytime Python or ZCML code is changed you should restart Zope clients. Exceptions include changes to the process method of modeler plugins or command parsers.
- zendmd (though not a daemon)
Collector daemons should most likely not be running at all on a development system. They can be run only when you need to test collection. This avoids the necessity of knowing when they need to be restarted.