Having some issues with CS Discovery and when looking at the CSDiscovery log file the following error occurs
log4j:WARN No appenders could be found for logger (com.cisco.nm.csdiscovery.CSDiscoveryManager).
log4j:WARN Please initialize the log4j system properly.
Can you assist me with what this means and how to fix
Discovery is taking a long long time to run...in fact it never finishes. I have to manually stop the service before it can be started again. The error I get when trying to stop it is "Unable to stop the running the discovery instance. Please check the log file C:/PROGRA~1/CSCOpx/log\CSDiscovery.log for more details." This is a real issue as I have discovery scheduled to run on a twice-daily basis
This is most likely CSCsv42110 which is fixed in LMS 3.2. Essentially, CSDiscovery waits for all of its worker threads to finish before the daemon stops, and discovery is reported as being complete. If something happens to one of these threads such that it dies, then the main thread monitor will wait forever. The workaround is to manually stop CSDiscovery using the command:
However, since LMS 3.2 is available, it is probably better just to upgrade. You can either download the upgrade from http://www.cisco.com/go/lms/ or order the upgrade DVD from http://www.cisco.com/upgrade/ by entering your SAS contract number.
That said, it would be useful to see the whole CSDiscovery.log to rule out any other problems.
Yeah, that is what I saw. With CSDiscovery shutdown, delete NMSROOT/conf/csdiscovery/DiscoveryStatusObj, and that should help a bit on the next run. However, Discovery will still have a tendency to lock up until you upgrade.
Other than that, I don't see any real issues.
No. This file is created when Discovery completes. If the last Discovery was terminated, the file may not have been created yet.
While it won't help the hanging problem, there could be some config optimizations that would help the overall Discovery time (even after upgrading). If you can, post your NMSROOT/conf/csdiscovery/CSDiscovery-config.xml file.
You've got a lot of community strings here. For example, the 10.31.*.* range has two strings each with 2 retries and a 3 second timeout. For each device that uses Hornsby Public, Discovery will spend at least an extra 21 seconds waiting for the device to timeout to Hornsby.
If possible try tightening the community string ranges, and that will certainly save you some time.