Auditd still crashing RHEL3/Centos3 systems
This is a well known issue, and it puzzles me that so many peoples don’t know about it. Still whenever I hear of peoples having random crashes with their systems, and they are running RHEL3, the first thing to check is if auditd is still enabled. Disabling auditd is the first things that I would recommend doing, and only after that if the problem still persists to look further into it. After recently doing this on several servers (you would think that most peoples took care of this by now, but it is not so…), I decided to post this in a separate blog entry so I can refer it, as a small step by step instructions anyone can do.
Why is this happening in the first place? Well RedHat had the bad idea to enable by default auditd on RHEL3. After seeing how many peoples had problems with it, I should conclude that this was one of the worse idea they could have… Anyway, the problem is seen either by random, inexplicable system crashes, or by filling up the hdd with huge audit.d logs.
This post will show how you can disable auditd and should be useful to any RHEL3/Centos3/whatever other rhel clones users that have similar problems. The RHEL3 and CPanel combination is the favorite deployment for many US datacenters and this is also very common. Of course this could be useful for other RHEL versions or even other Linux distributions if needed.
1. Check if auditd is indeed running.
If auditd has not been explicitly stopped on a rhel3 system you will have it running. You can check it out by running:
service audit statusand if you get something like:
auditd (pid xxx) is running...then you have it running.
Also you can see in the list of running processes if auditd appears:
ps -ef | grep auditd
2. Stop the auditd service
You can stop the auditd daemon by running:
chkconfig audit off
service audit stopThe first command should prevent the service from starting again on system reboot and the last one stops the active service.
3. Removing the audit module
You would think that this was it… and what was the reason for this post? to show how you can stop a service? Nope… there is more. Actually you might see problems on systems even with the auditd daemon not running but with the kernel module still loaded. In this case where we are now, we still have the audit kernel module running and doing ‘its work’
. You can check this with:
lsmod | grep audittrying to remove the kernel module:
rmmod auditwill give a busy error (as the module is still in use)… Who is using still using it? Well on default rhel3 systems cron and atd are still using it. So in order to remove it we need first to stop those services:
service crond stop
service atd stop
rmmod auditNow the module should no longer be loaded and you can check that out with:
lsmod | grep audit4. Prevent the audit module from loading again
If we don’t do this step when we start back the cron service we will load back the audit kernel module.
echo "alias char-major-10-224 off" >> /etc/modules.confThis will prevent the module to load again. And now we can restore the services that were running back:
service crond start
service atd start(start only the ones you had running – most certainly cron, but atd might not be needed on all systems).
5. Remove existing audit.d logs
You might want to remove the audit logs as this can be a huge amount of useless information:
rm -Rfv /var/log/audit.d/
rm -fv /var/log/audit List of commands used:
service audit status
chkconfig audit off
service audit stop
service crond stop
service atd stop
rmmod audit
lsmod | grep audit
echo "alias char-major-10-224 off" >> /etc/modules.conf
service crond start
service atd start
rm -Rfv /var/log/audit.d/
rm -fv /var/log/audit>
Tags: auditd, kernel_modules, RHEL

2nd July 2007, 20:45
What does the audit service do? I have been experiencing a lot of ftp service crashes on my new Cpanel 11 box, could audit be interfering with it?
2nd July 2007, 21:11
Lane,
THis happens only on RHEL3/Centos3 boxes, because of a bug with these distros. If this is the case for you, disable audit and see if the problem still persists.
About auditd:
LauS (Linux Auditing System) Notes
Red Hat Enterprise Linux 3 Update 2 features LAuS, the Linux Auditing System. This system is composed of kernel-resident and user-space components that facilitate highly-configurable and robust logging of system call use. This document provides an overview of how the auditing system is put together and basic information on how to get it running. Pointers to relevant documentation are also provided that should help in making the best use of this new capability.
LauS Overview
LauS consist of two types of components:
* The kernel component
* The User-space components
Kernel Component
The default kernel provided with Red Hat Enterprise Linux 3 Update 2 contains modifications that enable system-call auditing. When auditing is not in use, these modifications are performance-neutral. The kernel component provides access to the auditing facilities through a character-special device — /dev/audit. Through this device, a user-space daemon (auditd) can enable or disable auditing and can provide the kernel with the rulesets it is to use to determine when an invocation of a system call must be logged. This device is also used by auditd to retrieve audit records from the kernel for transfer to the audit log. Refer to the audit(4) man page for information about supported ioctl() calls and /proc/ interfaces for managing and tuning auditing behavior.
User-Space Components
There are a number of programs provided that transfer audit records from the kernel to the audit log and manipulate the resulting data. These programs and their documentation are found in the laus package.
Auditing is performed for a process if that process registers itself with the kernel as auditable. This registration is propagated to any process started from a registered process. Modifications were made to PAM to assure the auditing of all user sessions when kernel auditing is enabled.
auditd
… from: http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/as-x86/RELEASE-NOTES-U2-x86-en.html
21st April 2008, 17:23
Or you could just clean all the save files out of /var/log/audit.d and move away the bin files, so that auditd will create new ones on restart. If you don’t already have a login on the machine, you will have to reboot it via Ctrl-Alt-Del, and then boot into single user mode (see grub man pages) to effect these changes.
If the problem is persistent, after cleaning up, you can increase the audit log file size in /etc/audit/audit.conf; change the 20M to 40M or 80M, and then restart the machine (or auditd, if the machine is still up and you have console access). Auditd is actually important for incident analysis, as it records all commands run on the machine. Disabling it probably isn’t the answer in a production environment.
-Adam
22nd April 2008, 21:08
Adam: thanks for your comment; I agree with you that auditd is a useful tool; this post was targeted at rhel3 systems that had problems and had an unresolved bug at that time.
20th October 2008, 21:09
Has anyone seen this type of behavior with CentOS4? We’re up and running for random amounts of time, sometimes weeks, sometimes days. We’ve got auditd disabled on all the affected servers. Every now and then the system just seems to lock itself up. It stops accepting new ssh or console sessions but is still pingable. We’ve got to rebot it to get it back. A reboot gets it right back up and running. There is heavy ssh traffic to these boxes, frequent opening / closing of sessions. I don’t see any log files at all in the auditd log directory.
21st October 2008, 05:26
Chris: Personally I am not aware of this issue happening on other systems besides RHEL3/Centos3, but maybe some other users will have a different experience that might help you with your problem.
22nd January 2009, 19:27
We had a real problem with this at the bank I work at. The ssh daemon would just stop working and Oracle would have issues. We are using tripwire and a centralized logging host monitored by a data sercurity group as our audit system. We disabled it for this reason. Granted this only works for large conmanies, but audit has caused me more problems then it saved.