
The file messages in /var/log (Linux) or /var/adm (Solaris) will show any errors that the Agent processes
had before being able to write to the DebugEvent_Default.dbe file. You may need to check the
/etc/syslog.conf to validate that errors are being written to this file.
You can also cause the agent to log some informational messages to the messages file. In the file
/opt/CMAgent/ECMu/1.0/scripts/inetd-agent, add a –b immediately before the –u. This will cause the
CsiAgentListener to log information about which user it is using, the group it is using and each step as it
daemonizes itself to detach from (x)inetd. It will also log when it exits. Again, you will need to check the
/etc/syslog.conf to validate that infos are being written to the messages file.
If you suspect that there is a race condition in the startup/shutdown and communications between the
CsiAgentListener and the Agent or KSrDaemon, you can cause informational messages to be logged to
the messages file. These will show each of the processes starting up, shutting down, checking to see if it is
safe to shutdown and determining that the process is available to be contacted. In the
/opt/CMAgent/ECMu/1.0/scripts/inetd-agent, add LOG_INFOS=1 immediately before CSI_REGISTRY_
PATH.
If inspections are failing, you can check /var/log/secure (Linux) or /var/adm/messages (Solaris) for
messages:
n
CSISecureHigh: Errors from the RunHigh executable meaning that there is some violation of the rules
enforced by the suid program for running root privilege inspections.
n
CSISecureLow: Errors from the RunLow executable meaning that there is some violation of the rules
enforced by the sgid program for running non-root privilege inspections.
n
CSISecure: Errors from the RunRemote executable meaning that there is some violation of the rules
enforced by the suid program for running root privilege remote commands. This executable is also
used in the File Upload job when it needs to copy a file that has restricted permissions.
The CSISecure* messages are deliberately not very useful in debugging as they would allow someone to
see the rules being enforced. Initial things to check are:
1. The user configured to run the Agent is a member of the cfgsoft group.
2. The user configured to run the Agent doesn’t have a default group of cfgsoft.
3. The user configured to run the Agent has a no-login shell.
These executables cannot be run manually or an error will be logged.
If inspections are not returning all of the expected information, the dbe file in the Collector’s request
directory can be examined. The file will display any errors that were reported to the stderr of the gawk
inspector. These messages will be from the ReadInternal function of the CEcmScriptResultStream class.
The message will indicate which data class was being processed at the time. The error may span several
sequential messages.
If the Agent does return a zrp file to the collector, any debug events will be logged in the SQL database
and can also be observed there. It is also possible to save the .zrp file by enabling the ‘SAS: Should SAS
data files be kept on the disk after they have been processed’ or the ‘ETL: Should ETL data files be kept on
the disk after they have been processed’ settings in the Administration->Settings->General Settings-
>Database grid of the VCM UI. The .zrp file will be called Results.zrp and will be stored in a request sub-
directory of the DSRoot directory.
Monitoring network traffic
In very rare cases, it may be useful to monitor the tcp traffic for the agent. The easiest way to do this is if
you have X windows access to the client and the ethereal package is installed.
UNIX Agent Troubleshooting
VMware, Inc. 63
Comentarios a estos manuales