Debugging Kernel Module Or Other File Monitoring Issues

You may detect a problem with the kernel module in a few different ways:

1. You may have noticed that you do not receive real-time file changes on the Enterprise Manager console for file changes that you know should occur.

2. In the Compliance Standard Target Associations or Real-time Observations page on the user interface, you may see an agent warning indicating a kernel module problem.

3. When examining the nmxcf.log file under AGENT_INST/sysman/logs, you may see errors indicating that the kernel module could not be loaded or used for various reasons.

If you encounter any of these issues, most likely there was a problem with compiling or inserting the Linux kernel module at run time.

You can confirm whether the auditmodule was loaded properly by running the following command.

grep -i auditmodule /proc/modules

If you do not receive any output, then the auditmodule is not loaded and the agent will not perform real time file monitoring.

If the audit module file was generated properly and it does not show up in the module list above, you can attempt to manually load the module to see if there are any errors. Use the following command where you replace {audit module file name} with the entire name of the .ko file that was created from compmod.sh:

insmod {audit module file name}

If you experience no errors during this command, you can check the module list again by using the grep command above. If the audit module now appears, then the file monitoring capability should work. An agent restart is necessary; however there still may be a problem with the file monitoring process finding the .ko file which you will experience again next time your host is rebooted.

One additional step to debug any issues with the file monitoring process is to try to run it manually. To do this, follow these steps:

1. Get the process ID of the agent TMMain process:

   ps –eaf |grep TMMain

2. Execute the nmxcf process using the following command replacing the values in {} with the proper path elements or the process ID from the previous command:

   sudo {agent_home}/core/{agent_version}/bin/nmxcf -e {agent_home}/agent_inst/ -m {agent_home}/agent_inst/sysman/emd/state/fetchlet_state/CCCDataFetchlet –w {process id of TMMAIN}

Running the nmxcf process this way will not work in the long term since it will not start up again when the agent is restarted, but this can help in trying to debug any issues as to why the process cannot start.

If the module still is not able to load and if you need to contact Oracle support about the issue, please be sure to include the following information with your support ticket:

• Output of the command: uname -a

• Output of the command: grep –i auditmodule /proc/modules

• Output of the command: rpm –q –a |grep –i kernel-devel

• The make.log and build.log files from the /opt/fileauditmodule directory where you ran compmod.sh if you built your own .ko file

• The files AGENT_INST/sysman/log/nmxc*.log

• Any warnings or errors you received when trying to start nmxcf manually.

This information will help Oracle Support to determine if the real time file monitoring audit module of the agent can be built on your environment.

Note:

Be careful when using the Linux OS command rmmod which is used to unload a kernel module. If the nmxcf binary is running and you use rmmod, there is a chance that a kernel panic can arise by trying to unload a kernel module in use. The use of rmmod in Linux should be done carefully no matter which module you are unloading.