Red Hat Bugzilla – Bug 177321
audit daemon off, continued errors in /var/log/cron log
Last modified: 2007-11-30 17:07:09 EST
Description of problem: We run production servers with RHEL 3.0 WS U4 + patches. We ran out of disk space on the /var partition due to the audit subsystem configuration, and decided to turn off the audit daemon. We then found Bugzilla Bug 131860 that described problems with cron logging after the audit daemon was turned off. We subsequently upgraded to the recommended vixie-cron version (vixie-cron- 3.0.1-76_EL3.i386.rpm), and had success in our lab environment. When we deployed in production (two servers so far), we see the following logs every time cron jobs are run. CROND[28602]: LAuS error - do_command.c:182 - laus_log: (19) laus_log: No such device CROND[28603]: LAuS error - do_command.c:182 - laus_log: (19) laus_log: No such device NOTE: there are no laus_attach logs generated. We restarted cron and at daemons, but the logs still come! Version-Release number of selected component (if applicable): 3.0.1-76_EL3 How reproducible: Always (on our production machines) Steps to Reproduce: 1. Stop the audit daemon /etc/init.d/audit stop 2. Configure audit not to run at boot time /sbin/chkconfig audit off 3. Clear out all old audit logs rm -Rf /var/log/audit.d rm -f /var/log/audit 4. Upgrade to the new vixie-cron package rpm -Uvh vixie-cron-3.0.1-76_EL3.i386.rpm Actual results: Log file shows laus errors every time a cron job runs. CROND[28602]: LAuS error - do_command.c:182 - laus_log: (19) laus_log: No such device Expected results: Should see a single laus_attach error (below), and no additional errors. LAuS error - do_command.c:226 - laus_attach: (19) laus_attach: No such device. Additional info: -
I'm not able to reproduce this problem here, ie. seeing the log message: 'LAuS error - do_command.c:182 - laus_log: (19) laus_log: No such device '. The issue would appear to be with the kernel support for the /dev/audit file, which gets created during the initial installation of the laus package, with: # /bin/mknod /dev/audit c 10 224 and is supported in the kernel by the audit module. The 'audit' module must be installed, otherwise I/O operations on this file will fail with errno set to ENODEV (19) : 'No such device' - ie. the command # lsmod | grep audit should find the audit module. If the main crond process has succeeded in the initial open of /dev/audit, (LAuS auditing is enabled), each cron job child process attempts to do LAuS logging ioctls to the file descriptor for this file. So what appears to have happened to your servers is that the main crond process initially succeeded in opening /dev/audit, so LAuS logging is enabled in the main crond process, but then the 'audit' kernel module was removed, so that subsequent writes by crond child processes fail, and the 'laus_log: No such device' message is generated. But I am unable to get a system into the state of any process having open file descriptors to the audit device, and then being able to uninstall the audit module. The logging of this error message: 'LAuS error - do_command.c:182 - laus_log: (19) laus_log: No such device' should disappear after restarting crond or rebooting the machine. Please supply some further information: 1. On the systems where the problem occurs, is the audit module installed ? If not, does just doing an # modprobe audit stop the log messages being generated ? 2. Does restarting crond fix the problem ? (crond should have been restarted during upgrade - if not, this could be the cause of this bug - but I've not been able to reproduce this either). 3. Does the problem persist after rebooting the machine ? 4. What version of the kernel are you running ? Several bugs with the laus/audit modules in the kernel were fixed, and you'd be advised to upgrade to the latest kernel-2.4.21-37.EL in RHEL-3-U6 .
Answers to the questions: 1. The audit module is installed (stock kernel) - lsmod | grep audit returns an answer (see eg) [root@customer1 root]# lsmod | grep audit audit 90744 2 - doing a modprobe audit had no effect on the cron logging problem 2. Restarting the cron daemon has no effect on the logging problem either 3. After a reboot, the logging stops 4. We're running a post U4 kernel (but will not upgrade to U6 until March) 2.4.21-27.0.2.ELsmp We're not removing the audit module; if we did, wouldn't we have to do so every time we upgrade kernels? The module is installed by default in RHEL, correct?
Hello, sorry for not replying so long. Did you update to the latest-kernel? And have you still problems? It sounds to me like problem non related to cron.
This problem will be resolved in a future major release of Red Hat Enterprise Linux. Red Hat does not currently plan to provide a resolution for this in a Red Hat Enterprise Linux update for currently deployed systems.