Welcome Serena Central users!
The migration of the Serena Central community is happening today. Be sure to read THIS MESSAGE to get your new login set up to access your account.
edbarrag Absent Member.
Absent Member.
700 views

log.msq.cmdctrl and log.msq.cmdctrl.tmp have a large size

Hello,

The activation of a new rule generated cmdctrl.db to grow significantly as well as log.msq.cmdctrl (24 gb) and log.msq.cmdctrl.tmp (67 gb). We proceeded to disable the rule, however log.msq.cmdctrl.tmp and log.msq.cmdctrl do not reduce its size.

How can I debug these files?
Can I delete them?

Regards!!
0 Likes
3 Replies
Micro Focus Expert
Micro Focus Expert

Re: log.msq.cmdctrl and log.msq.cmdctrl.tmp have a large si

These files are used to store keystroke audit data and are part of the audit collection process as far as I know. I don't think it would hurt anything to move / rename these files as backups if you are not interested in collecting the audits stored during this time frame. If this were my personal test environment, I would stop the pam service (npum stop) and then rename or move these files as backups, and start the npum service back up. I'd be monitoring the unifid.log for any problem. I also suspect errors will be found in the unifid.log that may help chase down any issue processing these audits if that is a concern.

What directory are these files found in?
Are they on the Agent or Audit Manager server?
0 Likes
edbarrag Absent Member.
Absent Member.

Re: log.msq.cmdctrl and log.msq.cmdctrl.tmp have a large si

thanks, tdharris:

In response to your questions I mention the following:

What directory are these files found in?
/opt/netiq/npum/service/local/audit/

Are they on the Agent or Audit Manager server?
Audit Manager

I remain attentive to any comment or doubt.
Regards!.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: log.msq.cmdctrl and log.msq.cmdctrl.tmp have a large si

Something to consider, we recommend configuring audit db rollover to help manage sizing of audit files for performance (./audit/cmdctrl.db):
https://www.netiq.com/documentation/privileged-account-manager-3/npam_admin/data/audit_settings.html

I believe audits are processed in this order (I could be wrong here):
- Agents deliver strfwd audits to Audit Managers -> received into log.msq.cmdctrl
- Audit Managers pick up audits from log.msq.cmdctrl and process them through log.msq.cmdctrl.tmp
- Once verified, then they are added to cmdctrl.db for viewing within the Reporting Console, etc.

So if the above is indeed true, then perhaps something is stuck in log.msq.cmdctrl.tmp. If it's important for you to process the remaining audits that have been growing in log.msq.cmdctrl, then perhaps we stop PAM, rename the .tmp one for backup purposes, then start PAM again and verify if a new file is created and if audits begin processing where log.msq.cmdctrl starts decreasing in size.

Although, perhaps the same issue occurs where new audits being processed get stuck in .tmp, then we could stop pam, rename both files for backup purposes, then start PAM and verify new audits are being captured and delivered to Audit Manager appropriately.

If it is important to process these now backed-up audits, then the manager's unifid.log in DEBUG needs to be reviewed to determine a cause of the failure to process these previous audits. At that point, I'd recommend capturing a copy of the unifid.log and opening a Service Request unless you are able to find a reason in the log. Engineering can help clean the bad audits from these files and we could inject them back for processing, but a Service Request would be necessary to track and manage this.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.