Troubleshooting
Problem
On a database server where the Guardium STAP and KTAP are installed you find that the ktap.log is growing very large. It is filled with messages like: Jan 13 01:15:34 hostname kern:debug unix: (v 37105) GUARD-02: 29163892 is_db2shmem_request: is_db2shmem_request: Can't get free request (49) (line 4620)
Symptom
The <guardium_install_directory>/ktap/current/ktap.log is filled with messages, for example:
Jan 13 01:15:34 hostname kern:debug unix: (v <ktap version>) GUARD-02: 29163892 is_db2shmem_request: is_db2shmem_request: Can't get free request (49) (line 4620)
Cause
There are two known causes:
- KTAP debugging has been turned on. This can be done directly on the database server using the script in the resolving section. It may have been turned on in the past for troubleshooting and over time has grown the file size.
- If the monitored database is DB2, incorrect configuration of inspection engine parameters can cause this problem.
Resolving The Problem
Ensure that KTAP debug has been turned off by running the below commands on the affected DB server.
1. <guardium_install_dir>/ktap/current/guard_ktap_log set 0
2. <guardium_install_dir>/ktap/current/guard_ktap_log set +0
If the problem is not resolved and you are monitoring a DB2 database. Ensure the inspection engine parameters are set correctly. See:
under section "How to determine DB2 parameters".
Setting KTAP debug to 0 will not totally stop messages being added to the ktap.log file. The messages added at the different log levels are:
- 0 - KTAP_ERROR: Critical failures. E.g. fail to load module or fail to trace a session.
1 - KTAP_TRACE: Trace of IOCTL requests and session's open and close.
2 - KTAP_DEBUG: All activities of all sessions including pid, ports, mark, data length.
If the file is filling up the DB server even after running the commands above, you can totally stop the logging with these steps:
- 1. In the /etc/syslog.conf file comment out the line with /var/log/ktap.log in it so it appears like.
- #local0.err,kern.debug /var/log/ktap.log
- # refresh -s syslogd
0513-095 The request for subsystem refresh was completed successfully.
Important note! If the ktap.log file is filling up the server with the debug set to 0 this indicates another problem and steps should be taken to investigate this. If a PMR with IBM Support is required, attach the following information:
- Output of guard_diag script run on server with the problem
- Copy of ktap.log file
Related Information
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21694829