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

Answered Question
Nov 9th, 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

Correct Answer by Joe Clarke about 7 years 3 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Joe Clarke Mon, 11/09/2009 - 15:54

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.

Joe Clarke Mon, 11/09/2009 - 16:14

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.

Joe Clarke Mon, 11/09/2009 - 16:29

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 Mon, 11/09/2009 - 16:39

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?

Correct Answer
Joe Clarke Mon, 11/09/2009 - 16:45

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

eidumsigfrid Mon, 11/09/2009 - 16:55

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.

eidumsigfrid Tue, 11/10/2009 - 13:47

Cheers, Joe. :)

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

Actions

This Discussion