Solved: URN_NOT_FOUND : urn "ogs_server_urn" : Not found - daemonsbackup.log

eidumsigfrid · ‎11-09-2009

Hi,

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 !!

at com.cisco.nm.xms.ctm.client.CTMCall.establishIPC(CTMCall.java:238)

at com.cisco.nm.xms.ctm.client.CTMCall.<init>(CTMCall.java:218)

at com.cisco.nm.xms.ctm.client.CTMClientProxy.<init>(CTMClientProxy.java:64)

at com.cisco.nm.xms.ctm.client.CTMClientProxy.getProxy(CTMClientProxy.java:180)

at com.cisco.nm.xms.ogs.client.OGSServerProxy.init(OGSServerProxy.java:179)

at com.cisco.nm.xms.ogs.client.OGSServerProxy.init(OGSServerProxy.java:98)

at com.cisco.nm.xms.ogs.client.OGSServerProxy.<init>(OGSServerProxy.java:85)

at com.cisco.nm.trx.nos.server.EPMPoller.ogsVerifyService(EPMPoller.java:212)

at com.cisco.nm.trx.nos.server.EPMPoller.<init>(EPMPoller.java:144)

at com.cisco.nm.trx.nos.server.NOSServer.initializeEPMPoller(NOSServer.java:244)

at com.cisco.nm.trx.nos.server.NOSServer.<init>(NOSServer.java:107)

at com.cisco.nm.trx.nos.server.NOSServer.main(NOSServer.java:259)

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.

Cheers,

Sigfrid

Joe Clarke · ‎11-09-2009

Yes, but that process must be stale. Shut down dmgtd, then kill off any remain brstart or sm_server processes. Then restart dmgtd.

View solution in original post

Joe Clarke · ‎11-09-2009

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.

eidumsigfrid · ‎11-09-2009

Hi Joe,

The problem is occuring at the moment according to "tail -f daemons.log". Logs attached (had to zip up the daemons.log).

Cheers,

Sigfrid

Joe Clarke · ‎11-09-2009

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.

eidumsigfrid · ‎11-09-2009

Output attached.

Joe Clarke · ‎11-09-2009

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.

eidumsigfrid · ‎11-09-2009

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?

Joe Clarke · ‎11-09-2009

Yes, but that process must be stale. Shut down dmgtd, then kill off any remain brstart or sm_server processes. Then restart dmgtd.

eidumsigfrid · ‎11-09-2009

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.

Joe Clarke · ‎11-09-2009

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... .

eidumsigfrid · ‎11-10-2009

Cheers, Joe. :)

Applying the patch seems to have resolved the issue. I haven't seen the error since.