excessive growth of NMSROOT/conf/csdiscovery/DiscoveryStatusObj

Answered Question
Feb 16th, 2009
User Badges:
  • Blue, 1500 points or more

is there any known reason which could lead to an excessive growth of NMSROOT/conf/csdiscovery/DiscoveryStatusObj?

I know that the file holds all information of the last (or current) discovery job. But in a network with around 100 devices I've got the feeling 7GB is a huge amount of data;

As well this did happen only for one discovery cycle which finally leads to other failed processes because the system was running out of diskspace. To recover the system, I stopped and restarted dmgtd and deleted the file; The subsequent discovery processes did run without a problem as before.

Is there a possibility to troubleshoot the cause of this behaviour and to prevent the system from killing itself (by eating up the whole diskspace)?


Correct Answer by Joe Clarke about 8 years 5 months ago

No. The problem has been reported about 18 other times. In every case, the file was simply deleted, and a new Discovery was run. It rarely comes back.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Joe Clarke Mon, 02/16/2009 - 09:44
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

This file not only contains the last Discovery status, but also a record of all of the device structures. These are actually serialized Java objects, and can be quite complex. If this file is getting too big, you can simply delete it


Figuring out why some Discovery runs produce a larger serialized class would require analyzing the contents of the serialized class. This could be done, but only by Cisco.

Martin Ermel Mon, 02/16/2009 - 10:11
User Badges:
  • Blue, 1500 points or more

What would be the correct way to get this analayzed by Cisco?

a) If CSDisocvery does not terminates correctly:

Stopping dmgtd; backout DiscoveryStatusObj; delete the original file; restart dmgtd; open a SR and upload the file;

b) If CSDiscovery does terminate:

backout DiscoveryStatusObj; delete the original file; open a SR and upload the file;


is there any other information needed?

It would be greate to know as in most cases a customer wants to have the system running again asap.

Joe Clarke Mon, 02/16/2009 - 10:25
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

When the file grows out of control, then just send it. The file is deleted every time Discovery starts, and re-written when Discovery completes. So when the file is big, regardless of the state of Discovery, it should be useful.

Martin Ermel Mon, 02/16/2009 - 10:43
User Badges:
  • Blue, 1500 points or more

are there known issues what could cause this behaviour?

Correct Answer
Joe Clarke Mon, 02/16/2009 - 10:45
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

No. The problem has been reported about 18 other times. In every case, the file was simply deleted, and a new Discovery was run. It rarely comes back.

Martin Ermel Mon, 02/16/2009 - 11:13
User Badges:
  • Blue, 1500 points or more

Thank you very much for this info! I have currently 2 customers which have had this issue at least once. Both are installations of LMS 3.1 on windows; If I have got the possibility I will try and get DiscoveryStatusObj the next time.

Actions

This Discussion