Solved: processes "Never started" in LMS 2.6

yjdabear · ‎04-30-2007

I have four processes that are "Never started". Of these, UTMajorAcquisition and DeviceDiscovery surely should not have been, since Data Collection and User Tracking Acquisition have been running successfully every night.

14. DeviceDiscovery Never started 0 0 0 N/A Not applicable

18. EDS-TR Never started 0 0 0 N/A Not applicable

22. FDRewinder Never started 0 0 0 N/A Not applicable

40. UTMajorAcquisition Never started 0 0 0 N/A Not applicable

A second concern is, one of the cat6k running CatOS started failing in the Inventory Collection job (as well as the Inventory Polling job it spawned in turn) scheduled via RME - Admin - Inventory - System Job Schedule:

RICS0001:Internal Error,unable to process the collected data from the device.

Joe Clarke · ‎04-30-2007

DeviceDiscovery is a transient process which means its healthy states are "Program started - No mgt msgs received", "Transient terminated", or "Never started".

EDS-TR should never be running. It is unused, and will be removed in a future release.

FDRewinder is used to aid in the rotation of daemons.log. It is also a transient, and its healthy states are "Program started - No mgt msgs received", "Administrator has shut down this server", or "Never started".

UTMajorAcquisition is also a transient just like DeviceDiscovery.

If these processes are never started, that means dmgtd has since been restarted.

The RICS0001 error could be related to a known inventory collection bug that affects a lrge number of devices (CSCse52700). A patch is available by calling the TAC, and referencing this bug. However, before a conclusion can be drawn, the IC_Server.log must be collected to confirm that this is the correct bug.

View solution in original post

Joe Clarke · ‎04-30-2007

Yes. Device Discovery's only purpose is to add devices to DCR. It is not required to put devices on the Topology Map or perform User Tracking acquisitions.

View solution in original post

Joe Clarke · ‎04-30-2007

DeviceDiscovery is a transient process which means its healthy states are "Program started - No mgt msgs received", "Transient terminated", or "Never started".

EDS-TR should never be running. It is unused, and will be removed in a future release.

FDRewinder is used to aid in the rotation of daemons.log. It is also a transient, and its healthy states are "Program started - No mgt msgs received", "Administrator has shut down this server", or "Never started".

UTMajorAcquisition is also a transient just like DeviceDiscovery.

If these processes are never started, that means dmgtd has since been restarted.

The RICS0001 error could be related to a known inventory collection bug that affects a lrge number of devices (CSCse52700). A patch is available by calling the TAC, and referencing this bug. However, before a conclusion can be drawn, the IC_Server.log must be collected to confirm that this is the correct bug.

yjdabear · ‎04-30-2007

Is the following snippet from IC_Server.log on the failed device sufficient to make a determination whether it's hitting CSCse52700?

[ Sat Apr 28 12:45:39 EDT 2007 ],INFO ,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,194,Started processing device Name: 10.108.25.76

[ Sat Apr 28 12:45:44 EDT 2007 ],INFO ,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,239,DP time is 5 seconds for 10.108.25.76

[ Sat Apr 28 12:45:49 EDT 2007 ],INFO ,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,454,Total time before Callback is 10 seconds for 10.108.25.76

[ Sat Apr 28 12:45:49 EDT 2007 ],INFO ,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,457, Finished processing device 708 10.108.25.76

[ Sat Apr 28 12:45:49 EDT 2007 ],INFO ,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,463,Total time is 10 seconds for 10.108.25.76

[ Sun Apr 29 12:45:27 EDT 2007 ],INFO ,[Thread-22],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,194,Started processing device Name: 10.108.25.76

[ Sun Apr 29 12:45:32 EDT 2007 ],INFO ,[Thread-22],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,239,DP time is 4 seconds for 10.108.25.76

[ Sun Apr 29 12:45:32 EDT 2007 ],ERROR,[Thread-22],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,433, Exception occured in process method while processing: 10.108.25.76 ASA Error -193: Primary key for table 'PhysicalElement' is not unique

[ Mon Apr 30 12:45:43 EDT 2007 ],INFO ,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,194,Started processing device Name: 10.108.25.76

[ Mon Apr 30 12:45:47 EDT 2007 ],INFO ,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,239,DP time is 4 seconds for 10.108.25.76

[ Mon Apr 30 12:45:48 EDT 2007 ],ERROR,[Thread-19],com.cisco.nm.rmeng.inventory.ics.core.CollectionController,433, Exception occured in process method while processing: 10.108.25.76 ASA Error -193: Primary key for table 'PhysicalElement' is not unique

Joe Clarke · ‎04-30-2007

Yes. You are hitting the aforementioned bug.

yjdabear · ‎04-30-2007

Another question: Campus Manager Device Discovery seems to be populating DCR with discovered devices. In LMS 2.2, there's a checkbox to disable a similar behavior (sync to RME). I haven't found an equivalent to that. Is disabling Device Discovery the only option?

Joe Clarke · ‎04-30-2007

Yes. Device Discovery's only purpose is to add devices to DCR. It is not required to put devices on the Topology Map or perform User Tracking acquisitions.