Bug 131860 - (IT#49661) cron and laus problem
cron and laus problem
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: vixie-cron (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
: 132170 laus/audit 144994 (view as bug list)
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-09-05 16:15 EDT by Marius Onica
Modified: 2007-11-30 17:07 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-19 20:05:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marius Onica 2004-09-05 16:15:47 EDT
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:
Comment 1 Charlie Bennett 2004-09-08 13:26:54 EDT
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.
Comment 2 Bill Nottingham 2004-09-09 12:13:19 EDT
*** Bug 132170 has been marked as a duplicate of this bug. ***
Comment 3 Tom Diehl 2004-09-28 10:23:23 EDT
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.
Comment 4 Charlie Bennett 2004-09-28 11:02:10 EDT
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.
Comment 8 Dr. Stephan Wonczak 2004-10-22 04:25:53 EDT
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.
Comment 9 Pancrazio `ezio' de Mauro 2004-10-25 06:11:22 EDT
*** Bug 136657 has been marked as a duplicate of this bug. ***
Comment 10 Steven Roberts 2004-10-29 20:24:16 EDT
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).
Comment 11 glshank 2004-12-03 12:50:17 EST
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
Comment 12 Charlie Bennett 2004-12-03 14:07:32 EST
Removing /dev/audit will work beautifully.  Thanks!


Comment 14 Chris Stankaitis 2004-12-08 09:03:37 EST
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?
Comment 15 Charlie Bennett 2004-12-08 16:29:11 EST
service crond restart
service at restart
Comment 16 Chris Stankaitis 2004-12-13 15:29:51 EST
as expected kicking cron fixed the issue, the Laus Logwatch spam is
now gone from the 3 servers we were seeing the issue on.
Comment 17 Charlie Bennett 2005-01-13 11:57:59 EST
*** Bug 144994 has been marked as a duplicate of this bug. ***
Comment 18 Charlie Bennett 2005-02-01 15:42:39 EST
*** Bug 144923 has been marked as a duplicate of this bug. ***
Comment 20 Jason Vas Dias 2005-02-14 15:54:34 EST
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 


Comment 22 Tim Powers 2005-05-19 20:05:16 EDT
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
Comment 23 Cott Lang 2005-09-26 10:26:58 EDT
U5 has come and gone, but the fixed version of vixie-cron is not in there. 

???
Comment 24 Jason Vas Dias 2005-09-26 11:34:14 EDT
(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.


Note You need to log in before you can comment on or make changes to this bug.