From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
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
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):
Steps to Reproduce:
2.watch the log files
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
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
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.
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
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:
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.
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