CM 4.0.8: UT CLI problem

Unanswered Question
Aug 2nd, 2007

Receiving log4j errors with the UT CLI command:

/opt/CSCOpx/campus/bin/ut -cli -query all -export /path/ut.txt -u admin -p password

log4j:ERROR No appenders could be found for category (

log4j:ERROR Please initialize the log4j system properly.

Operation has been completed successfully

Is this related the following problem?

Process= DeviceDiscovery

State = Transient terminated

Pid = 0

RC = 0

Signo = 0

Start = 08/01/07 11:39:08

Stop = 08/01/07 11:40:15

Core = Not applicable

Info = Application started by administrator request.

Process= UTMajorAcquisition

State = Transient terminated

Pid = 0

RC = 0

Signo = 0

Start = 08/02/07 00:00:00

Stop = 08/02/07 00:28:06

Core = Not applicable

Info = Application started by administrator request.

Process= FDRewinder

State = Transient terminated

Pid = 0

RC = 0

Signo = 0

Start = 08/01/07 11:41:45

Stop = 08/01/07 11:41:45

Core = Not applicable

Info = Application started by administrator request.

tail -f /var/adm/CSCOpx/log/ut.log


2007/08/02 00:19:30 EvalTask-vmpsadmin-07 ani WARNING C6KIOSVmpsAdminSMFGetBridgeTable: VladSMFGetVlanPorts.getData() returns null for device xx.xx.xx.xx, no CAM table read.

2007/08/02 00:25:38 main ani MESSAGE DBConnection: Created new Database connection [hashCode = 5742829]

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Joe Clarke Thu, 08/02/2007 - 12:46

These log4j errors are normal, and do not cause any problem. ut -cli should always display the log4j errors, but still complete the desired operation. Nothing in the output you have provided is necessarily problematic.

yjdabear Fri, 08/03/2007 - 09:21

There's another factor that makes me think something went wrong--CM status as of this moment:

Device Discovery 01 Aug 2007, 11:40:14 EDT xxxx Devices Idle Start Device Discovery

where xxxx is over a hundred devices shy of the total number of devices in the DCR.

Joe Clarke Fri, 08/03/2007 - 10:55

This is not necessarily a problem. You can add devices to DCR outside of discovery, and Discovery can also use filters to prevent it from counting devices that are in DCR. In order to determine if this is a real problem, you will need to find one device that is in DCR, but missing from Discovery's last sweep, then look through the discovery.log (assuming devdiscovery debugging was enabled) to see why that device might be missing. Look for that device's name and address as well as its neighbors names and addresses.

yjdabear Fri, 08/03/2007 - 11:15

Device Discovery had always had more devices than what's in DCR (equal to the device number in CM's Data Collection) until this juncture. Most of the extraneous ones found by Device Discovery are "unreachable", and I disabled the Device Discovery=>DCR synchronization. Since I don't have debug on for discovery, should I still bother looking for a device? I did just see the following:

tail -f discovery.log

2007/08/01 11:40:13 EvalTask-Devdiscovery-07 WARNING DevdiscoverySMFGetDeviceType: SNMP unreachable device at: xx.xx.xx.xx will not remap SMFFactory

2007/08/01 11:40:14 main ERROR DevdiscoverySMFEnd: Error in add Device: CSTM Error Code [-23] CSTM Comm Type [0] - Error in reading/Error in received response,, Binary encoding InputStream does not contain a serialized object

2007/08/01 11:40:14 main MESSAGE DiscoveryMain: Properties will be read from /opt/CSCOpx/campus/etc/cwsi/

2007/08/01 11:40:14 main MESSAGE DiscoveryMain: Properties will be read from /opt/CSCOpx/campus/etc/cwsi/

2007/08/01 11:40:14 main MESSAGE DCRDevWrapper: Closing DCRProxy

Joe Clarke Fri, 08/03/2007 - 15:30

How did you disable DCR synchronization? The CSTM error here is a problem. This could indicate a problem with DCRServer or with the Campus CTM server (which should be ANIServer). The easiest thing to try to correct this would be a restart of dmgtd.

yjdabear Mon, 08/06/2007 - 11:22

I stopped the CM=>DCR device sync by deleting the Device Discovery schedule in CM completely.

Bouncing dmgtd is ok for a one-time anomaly, but I'm concerned the same problem might recur. Even though I've disabled Device Discovery and don't need it, I'm uncomfortable with the fact the "ut -cli" export also got affected by this problem--the output of the full ut dump was completely empty.

Joe Clarke Mon, 08/06/2007 - 11:32

If you've completely disable Discovery, then the CSTM error may be nothing to worry about. I still don't know what the problem with UT is. So far, you've only talked about Discovery numbers. These have no bearing on what is in User Tracking, and will not affect ut -cli.

yjdabear Mon, 08/06/2007 - 11:46

Never mind UT. I was looking at the wrong output file. The UT CLI dumps were successful.

Now I believe the Device Discovery that's stuck at 01 Aug 2007, 11:40:14 EDT has nothing to do with UT, but I just find the numbers of Physical and Logial Discrepancies are all zeros, whereas they had been in the thousands normally. Are these related to the CSTM error or Device Discovery (that's been stopped months ago)?

Joe Clarke Mon, 08/06/2007 - 11:58

Discrepancies have nothing to do with Discovery, either. Data Collection is solely responsible for detecting discrepancies. If the count suddenly dropped to 0, ANI either found a perfect network, or there was a problem with the last Data Collection. To debug discrepancy problems, enable dcrp debugging under Campus Manager > Admin > Campus Data Collection > Debugging Options, then re-run Campus Data Collection.

yjdabear Tue, 08/07/2007 - 11:29

Debugging was enabled, but no ani-trace.log was created as a result. I did not enalbe device-level debugging. Data Collection ran as usual, though it took ~34 mins last night compared to the ~25 mins the night before. The discrepancies are back once again. Strange.

Joe Clarke Tue, 08/07/2007 - 12:26

Indeed. If dcrp debugging was enabled, you should have seen something in ani.log related to discrepancies.


This Discussion