Red Hat Bugzilla – Bug 131860
cron and laus problem
Last modified: 2007-11-30 17:07:03 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040806 Description of problem: After installing vixie-cron-3.0.1-75.1, and not starting the audit subsystem with /etc/init.d/audit in var/log/cron it appears a lot of the following messages: LAuS error - do_command.c:226 - laus_attach: (19) laus_attach: No such device. Note 1. Te message appears whenever crond is executed Note 2. After starting the auditing subsystem everything is fine Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.start cron 2.watch the log files 3. Additional info:
My that is ugly! Assuming you want to run without auditd, try this: add this line to /etc/modules.conf: alias char-major-10-224 off then shut down crond and atd and make sure the auditd is not and will not run. This should drop the use count on the audit kernel module to 0 so that your can rmmod the module. Once you have you can restart crond and atd and they should henceforth run without those messages in the cron and at logs. The underlying issue is that the user space tools assume that if they can open the audit device then auditing is enabled. There is no provision for asking the audit device if there is an audit daemon registered. Given this state of affairs, the best option is to make it impossible to open the audit device if auditing is to be disabled.
*** Bug 132170 has been marked as a duplicate of this bug. ***
Sounds to me like the userspace tools are broken. Yes I can disable the module, but why is it assumed that everyone wants to run laus? If you are going to refuse to fix this why not at least document this proceedure.
Actually it's the interface between laus-kernel and laus-userspace. There's no way for the userspace liblaus to know until it's too late. We'll either document or find some a clean way to make this work right.
At least with our installation, the audit subsystem is worse than useless. We have a very busy mailserver and with the standard configuration we get about 2 GB of audit logs per day! To make things worse, at first we had not even noticed there even was an audit subsystem, but we noticed rather fast when the machine ground to a halt with a full /var ... Not pretty! So we switched the whole system off. And ran into these errors. Even less nice.
*** Bug 136657 has been marked as a duplicate of this bug. ***
encountered this problem as well. the workaround works fine here. A cleaner solution would be preferred, but as mentioned at least having it documented would be a good thing. which on my machines, platform is x86-64 (not i386).
Why is this work around necessary? Can't we just remove /dev/audit? Only one of my 6 Poweredge 6650 servers is having this problem and the only difference I can find between them is the existence of /dev/audit on the one exhibiting the problem. Please advise. Thanks, Greg
Removing /dev/audit will work beautifully. Thanks!
Can anyone else confirm this? I rm'ed /dev/audit and am still getting the logwatch spam on the box I was testing this fix on. Does anything need to be restarted. or anything special need to be done once /dev/audit is removed?
service crond restart service at restart
as expected kicking cron fixed the issue, the Laus Logwatch spam is now gone from the 3 servers we were seeing the issue on.
*** Bug 144994 has been marked as a duplicate of this bug. ***
*** Bug 144923 has been marked as a duplicate of this bug. ***
In the long run, it would be nice to have an ioctl to use to tell if auditd is running and all is OK with the audit subsystem. But then crond should not be filling up /var with repetitive error messages if there is a laus attach problem . So for now it will suffice to make vixie-cron print the error message only once if laus_attach fails. While laus_attach continues to fail after the initial failure, no log message will be emitted. Once laus_attach has succeeded, generation of the error message will be re-enabled until after laus_attach fails again. So, while crond is running, you can do: # service auditd stop You will then see ONE error message in /var/log/cron: LAuS error - do_command.c:226 - laus_attach: (19) laus_attach: No such device. when the next cron job is run. You will see no further laus error messages until you do: # service audit start Then you will again start seeing cron audit messages output by aucat, WITHOUT having to restart cron. If you then do # service audit stop you will see ONE more "LAuS error" message. This change is in vixie-cron-4.1-4_EL3 , which is now making its way through QA, hopefully into RHEL-3-U5 . Meanwhile, you can download it from: http://people.redhat.com/~jvdias/vixie-cron/RHEL-3
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-291.html
U5 has come and gone, but the fixed version of vixie-cron is not in there. ???
(In reply to comment #23): > U5 has come and gone, but the fixed version of vixie-cron is not in there. > > ??? This issue is fixed with the current vixie-cron-3.0.1-76_EL3 in RHEL-3-U5+ : crond will only emit ONE 'laus_attach failed' error message the first time it occurs, and then not until laus_attach succeeds and then fails again. If you have any issues with vixie-cron-3.0.1-76_EL3, please raise another bug report.