S-TAPs and other agents

These sections present troubleshooting and solutions for common problems with S-TAPs and other agents.

Error opening shared memory area when you configure Guardium COMM_EXIT_LIST for DB2
If you receive an error message when you configure Guardium COMM_EXIT_LIST, authorize the DB2 instance owner with the guardctl command.
Guardium fails to collect shared memory traffic from Informix
If Guardium fails to collect shared memory traffic from Informix, check the inspection engine configuration.
High CPU and I/O Use in Guardium S-TAP host
If you observe a high CPU or I/O usage, review the configuration for all of the inspection engines.
UNIX S-TAP cannot start: buffer size too large
If a UNIX S-TAP® cannot start, its buffer size might be too large.
S-TAP does not start automatically on Linux
If the S-TAP agent for DB2 or Oracle does not start automatically on Linux, check for the /etc/event.d/ directory.
S-TAP returns not FIPS 140-2 compliant
If you receive an error that about FIPS 140-2, change the configuration through the S-TAP Control page.
The K-TAP kernel module is still present after the uninstallation of S-TAP
If the K-TAP kernel module is still present after the uninstallation of S-TAP, manually remove it.
Windows S-TAP service crashes on startup with error ID 1000
If the S-TAP crashes with error ID 1000, check the SOFTWARE_TAP_IP parameter in the guard_tap_ini configuration file.
S-TAP is not capturing A-TAP traffic
Use the A-TAP script to output detailed information on the A-TAP configuration.
Linux S-TAP is not capturing Db2 exit traffic
Use the Db2 exit health check script to check and optionally fix the Db2 IE parameters.
Insufficient memory when installing UNIX S-TAP
If you receive the following error: modprobe: ERROR: could not insert ‘ktap’: Cannot allocate memory, your system might not have enough memory.

Parent topic: Problems and solutions