I've been trying to pinpoint why our LMS 3.2 Ciscoworks server shuts down all LMS processes on occasion.
The following is displayed repeatedly within the daemonsbackup.log
08/Nov/2009 03:17:16:265 ERROR ? ? - URN_NOT_FOUND : urn "ogs_server_urn" : Not found !!
com.cisco.nm.xms.ctm.common.CTMException: URN_NOT_FOUND : urn "ogs_server_urn" : Not found !!
08/Nov/2009 03:17:17:804 ERROR ? ? - URN_NOT_FOUND : urn "ogs_server_urn" : Not found !!
08/Nov/2009 03:17:17:805 ERROR ? ? - URN_NOT_FOUND : urn "ogs_server_urn" : Not found !!
08/Nov/2009 03:17:17:806 ERROR ? ? - URN_NOT_FOUND : urn "ogs_server_urn" : Not found !!
In EPMOgsAdapter:since isOGSup is not true
In EPMOgsAdapter:EPMOgsadapter is sleeping. Waiting for OGSServer to come up com.cisco.nm.xms.ctm.common.CTMException: URN_NOT_FOUND : urn "ogs_server_urn" : Not found !!
Has anyone else experienced this and how can I stop this error from appearing.
Solved! Go to Solution.
These messages are normal to see when dmgtd is starting. You need to post the complete daemons.log and output of the /opt/CSCOpx/bin/pdshow command when this problem is occurring before you restart dmgtd.
The DfmBroker daemon is dying which causes all of DFM to fail. Post the /opt/CSCOpx/objects/smarts/local/logs/brstart.log as well as the output of netstat -an.
Something on the server is already listening on tcp/9002. This port is required to be open for DfmBroker. If you have lsof installed, run:
lsof -i :9002
And that will tell you which process is listening. If you kill that process, then restart dmgtd, everything should come up. If you do not have lsof, you will need to comb through the output of pfiles for each process looking for one listening on tcp/9002.
I have a script that says port 9002 is in use by pid 28891 brstart --output --9002 ---user=casuer. Isn't that the process that starts Dfmbroker?
Ok will try that shortly. Is there a way to prevent this from occuring again. I suspect it starts after the LMS backup that is run weekly.
This is most likely related to CSCsx23656 which is fixed by applying the patch for CSCta56151 from http://tools.cisco.com/support/downloads/go/ImageList.x?relVer=3.2.0&mdfid=282640771&sftType=CiscoWorks+Device+Fault+Manager+Patches&optPlat=Solaris&nodecount=2&edesignator=null&modelName=CiscoWorks+Device+Fault+Manager+3.2&treeMdfId=268439477&treeNa... .
Cheers, Joe. :)
Applying the patch seems to have resolved the issue. I haven't seen the error since.