Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163223 - auditd initscript reports errors in default /etc/audit.rules
Summary: auditd initscript reports errors in default /etc/audit.rules
Alias: None
Product: Fedora
Classification: Fedora
Component: audit
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Steve Grubb
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-14 07:53 UTC by Paul Howarth
Modified: 2007-11-30 22:11 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-08-10 13:05:28 UTC

Attachments (Terms of Use)
strace of auditctl (deleted)
2005-07-16 17:08 UTC, Robert Hinson
no flags Details
strace auditctl -D 2> trace.txt (audit-0.9.19-1.FC4) (deleted)
2005-07-16 17:23 UTC, Paul Howarth
no flags Details
strace of running "auditcl -D" (deleted)
2005-09-05 13:12 UTC, Tomek
no flags Details

Description Paul Howarth 2005-07-14 07:53:30 UTC
Updated to audit-0.9.15-1.FC4 and now a restart of auditd results in:

# service auditd restart
Stopping auditd:                                           [  OK  ]
Error receiving watch list (Unknown error 4294967274)
Starting auditd:                                           [  OK  ]
Error receiving watch list (Unknown error 4294967274)
There was an error in line 5 of /etc/audit.rules

/etc/audit.rules unchanged from the default:
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.

# First rule - delete all

# Feel free to add below this line. See auditctl man page

# Increase the buffers to survive stress events
-b 256

The "error" does not appear to stop auditd from starting.

Version-Release number of selected component (if applicable):

How reproducible:
I have three systems exhbiting this issue, and was alerted to it by another user
on fedora-list. Same thing happens every time I try restarting auditd.

Comment 1 Steve Grubb 2005-07-14 13:15:05 UTC
This is a duplicate of #160318 & #161322.

Comment 2 Steve Grubb 2005-07-15 16:58:04 UTC
audit-0.9.19 was put into FC4 testing & rawhide. Please give it a try and let me
know if this works for you. Thanks.

Comment 3 Paul Howarth 2005-07-15 17:08:53 UTC
Did "yum --enablerepo=updates-testing update audit" and this updated audit and
audit-libs to 0.9.19-1.FC4. Still get the error message though:

# rpm -q audit
# service auditd restart
Stopping auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
Starting auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
There was an error in line 5 of /etc/audit.rules

Comment 4 Steve Grubb 2005-07-15 17:16:48 UTC
This looks like the old libs is still installed. I was thinking that updating
audit should update audit-libs as well. Did it miss that? Thanks.

Comment 5 Paul Howarth 2005-07-15 17:22:01 UTC
No, as I mentioned, audit-libs got updated too:

# rpm -q audit audit-libs

Comment 6 Robert Hinson 2005-07-15 23:33:19 UTC
The problem is the -D switch in the /etc/audit.rules.
If you look at the man page for auditctl and auditd, there is now -D switch.

Comment 7 Robert Hinson 2005-07-15 23:41:45 UTC
And if you type auditctl -D you get the same error.

Comment 8 Steve Grubb 2005-07-16 09:19:53 UTC
Could you attach an strace output to this bug report?

strace auditctl -D 2> trace.txt


Comment 9 Robert Hinson 2005-07-16 17:08:26 UTC
Created attachment 116842 [details]
strace of auditctl

Comment 10 Paul Howarth 2005-07-16 17:23:30 UTC
Created attachment 116843 [details]
strace auditctl -D 2> trace.txt (audit-0.9.19-1.FC4)

strace output from FC4 box with audit/audit-libs 0.9.19-1.FC4

Comment 11 Andre Ruiz 2005-07-16 23:00:44 UTC
If you run auditctl --help, there's a -D switch, but it's not in the man page,
and it triggers that error. Which is really odd (one would expect the opposite).

Comment 12 Steve Grubb 2005-07-17 16:13:26 UTC
Thanks for the straces. They show that the kernel is not liking the rules
request. This has been in kernels since 2.6.0. What kernels are you using and do
you have audit syscall support compiled in? auditctl appears to be correctly
reporting a kernel problem based on both straces.

Regarding -D, auditctl supports it. It was in the man pages and appears to have
been accidentally deleted. I added it back to the man pages, thanks for pointing
that out.

Comment 13 Eric Tanguy 2005-07-17 16:18:12 UTC
the straces are not from me but i have the same problem using the last fc4 stock
kernel 2.6.12-1.1398_FC4.

Comment 14 Paul Howarth 2005-07-17 17:32:36 UTC
The second strace (comment #10) was from me and I'm currently running
2.6.12-1.1390_FC4 on the machine that was from.

Comment 15 George N. White III 2005-07-18 22:48:30 UTC
2.6.12-1.1390_FC4 appears to have been configured for audit syscall support:

$ ls -l /lib/modules/2.6.12-1.1390_FC4/build/include/config/audit*.h
-rw-r--r--  7 root root 23 Jun  2 23:54
-rw-r--r--  7 root root 30 Jun  2 23:54
$ cat /lib/modules/2.6.12-1.1390_FC4/build/include/config/audit*.h
#define CONFIG_AUDIT 1

Comment 16 Ed Johns 2005-07-21 17:08:51 UTC
I am having the same roblem wih auditd.  Have the same audit.rules as the
original post.  I am running:

kernel 2.6.12-1.1398_FC4

When I execute auditctl -D I get:

Error sending rule list request (Invalid argument)
File system watches not supported

Comment 17 Steve Grubb 2005-07-27 12:58:14 UTC
I am using the same packages as listed above and I cannot reproduce the problem.
What arch is the kernels above? Did you ever have 2 instance of audit packages
installed? (up2date bug)  Did you rpm -Fvh the audit packages? Have you rebooted
since installing? Is there anything unusual about the system setup? Are you
mixing rawhide and FC4 packages? Are you tweeking SE Linux policy?

I'm kind of at a dead end without determining what is different about your
systems and how to reproduce.

Comment 18 Andre Ruiz 2005-07-27 13:19:27 UTC
Hi Steve!

This was a fresh FC4 install. No upgrades, nothing fancy. Just installed the
system and upgraded to the last packaged versions using yum. As soon as I can
remember after installing, the error was already there (maybe even before the
yum update). I think I saw it in the first reboot, inside the rhgb window.

- Kernel package: kernel-2.6.12-1.1398_FC4
- Never had 2 instances of audit installed, from what I remember
- Did not rpm -Fvh any package
- Rebooted many times, error always there
- Nothing unusual in the system setup
- Not mixing anything from others into FC4
- SELinux is disabled

If I can do anything to help, please tell me. Remote access to a system with
that problem would help?


Comment 19 Steve Grubb 2005-07-27 14:01:07 UTC
I still need the arch. Could you run uname -a and paste that into bugzilla. I'm
using 586 & 686 kernels. I have tried SE Linux disabled, but doesn't produce the
problem either. Are you using any security module in place of SE Linux? Do you
have anything LD_PRELOADED? Have you done anything with capabilities?

I might be interested in remote access if I can't figure out what is wrong
another way. However, to run auditctl, I need to have root access. So, I'd
prefer to duplicate the problem on my machine if at all possible.

Comment 20 Steve Grubb 2005-07-27 14:02:40 UTC
Also, how are you disabling SE Linux. Just curious.

Comment 21 Andre Ruiz 2005-07-27 14:20:03 UTC
- arch: x86 32 bits, AMD Sempron 3000+, ASUS A7V8X, GeForce 2 MX400

Linux foobar.mydomain 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686
athlon i386 GNU/Linux

- No other security modules
- Nothing changed in capabilities, at least not at will
- Disabled SE Linux in anaconda, during install.

$ grep -v ^# /etc/sysconfig/selinux

I did not touch that file after instalation, i'm just showing that it is
supposed to be disabled, according to it.

Comment 22 Ed Johns 2005-07-27 14:46:37 UTC
Linux system.domain 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686 i686
i386 GNU/Linux

I disabled selinux using system-config-securitylevel.  The
/etc/sysconfig/selinux file shows:


Nothing is LD_PRELOADED.

Comment 23 Need Real Name 2005-07-27 16:17:10 UTC
[root@localhost ~]# grep -v ^# /etc/sysconfig/selinux
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.12-1.1398_FC4smp #1 SMP Fri Jul 15 01:30:13 EDT
2005 i686 i686 i386 GNU/Linux

Comment 24 Steve Grubb 2005-07-27 16:57:21 UTC
OK. I'm able to reproduce. I have a feeling this is a kernel bug.

Comment 25 Andre Ruiz 2005-07-27 17:05:40 UTC
Just out of curiosity, what was missing in your setup and what info was the key
to reproduce it?

Comment 26 Steve Grubb 2005-07-27 17:12:27 UTC
Having SELINUX=disabled was the missing issue. This is not a normal
configuration for FC. I tried setenforce 0 and this did not do it. The reference
audit kernels do not exhibit this problem. I think there is a patch collision
kernel side.

Comment 27 Paul Howarth 2005-07-27 18:18:16 UTC
That's not quite solved it I'm afraid:

# uname -a
Linux 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT
2005 i686 athlon i386 GNU/Linux
# getenforce
# rpm -q audit audit-libs
# service auditd restart
Stopping auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
Starting auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
There was an error in line 5 of /etc/audit.rules

I'm not LD_PRELOADing anything. Nothing much fancy on this system. No custom
SELinux rules etc. Just rebooted after updating kernel and audit*.

I have other systems on which the combination of audit*0.9.19 and kernel
2.6.12-1.1398_FC4 has fixed this issue for me though.

Comment 28 Steve Grubb 2005-07-27 18:41:05 UTC
Paul, no one said it was solved. I just found out how to reproduce it. In the
system you are reporting on, SE Linux is permissive rather than enforcing. I'd
be willing to bet that the systems which are working are in enforcing mode and
systems with problems are either permissive or disabled.

Comment 29 Paul Howarth 2005-07-28 06:41:49 UTC
Ah, I thought from Comment #26 that you meant that "Permissive" and "Disabled"
behaved differently.

Turning on Enforcing does fix it, as you say:

# setenforce 1
# service auditd restart
Stopping auditd:                                           [  OK  ]
Starting auditd:                                           [  OK  ]
# setenforce 0
# service auditd restart
Stopping auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
Starting auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
There was an error in line 5 of /etc/audit.rules

The machine that was "fixed" earlier also was running in Enforced mode because
I'd sorted out the issues I was having with SELinux on that box. Time to do the
last couple of machines now. Thanks.

Comment 30 William Lovaton 2005-08-03 03:00:16 UTC
Just drop by to say "me too".  :-)

I disabled SELinux in anaconda during installation and I am seeing this too with
the updates from a month ago (more or less).

Linux athlon2000 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686 athlon
i386 GNU/Linux

[william@athlon2000 ~]$ grep -v ^# /etc/sysconfig/selinux

Although it says it fails, auditd seems to work ok.  Any idea about the problem?

Comment 31 David Woodhouse 2005-08-06 20:33:13 UTC
Look at the recvfrom() calls in that strace output. Pass it through 
           grep recvfrom | grep -v MSG_PEEK

Observe that we're only ever retrieving two packets from the netlink socket. The
check_ack() function doesn't actually dequeue the packet it peeks at, if it
detects an error. Thus, it's seeing the error for its second request repeatedly.

Comment 32 Trever Adams 2005-08-08 10:43:41 UTC
This happens on enabled and warn as well.

Comment 33 Steve Grubb 2005-08-08 18:21:12 UTC
Regarding comment #31, while this is "a" problem, it is not "the" problem. The
problem is in the 1st set of exchanges:

sendto(3, "\20\0\0\0\352\3\5\0\1\0\0\0\0\0\0\0", 16, 0, {sa_family=AF_NETLINK, 
pid=0, groups=00000000}, 12) = 16
Sent rule list request. seq #1

select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 100000})
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0P\16\0\0\0\0\0\0\20\0\0\0\352\3"..., 8476, 
MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) 
= 36
Check for ack. Got EINVAL back. Why? This is the bug !!!

I will update user space to make sure the bad packet gets eaten. I think we
still have the original problem.

Comment 34 Steve Grubb 2005-08-08 18:27:26 UTC
Actually, the first recvfrom is an ack, the 352 is too far to the right. Still

Comment 35 Steve Grubb 2005-08-09 12:56:16 UTC
audit-1.0.2 was released into rawhide. It will also be released to FC4 testing.
Could everyone please give it a try and let me know if it fixes the problem? Thanks.

Comment 36 Jacek Piskozub 2005-08-10 09:12:25 UTC
I tried audit-1.0.2 from FC4 testing (the development one was built for a newer
glibc so was unusable for me). The results are mixed.

Yes, the line 5 error happily went away (<joke>or at least was nicely hidden
from me</joke>). 

However, I still have another eoor: a shut-down error message that first
appeared at the same time at the "line 5" problem. It happens when system is
syncing hardware clock to system time. The error message says something about
audit daemon not found at pid=<pid_number>. No surprise about that as auditd is
being switched off before clock syncing. However, if I switch off the audit
daemon service, this error message goes away. And I never saw this error before

BTW, I use a fully updated FC4 with Selinux disabled. 

Comment 37 David Woodhouse 2005-08-10 09:19:26 UTC
The new error sounds like auditd is dying without 'signing off' by telling the
kernel that the audit_pid is now zero.

Comment 38 Steve Grubb 2005-08-10 13:05:28 UTC
The issue in comment #36 is bug 163500. You can add yourself to the cc list on
that bug if you want to. I will close this bug report based on positive
feedback. Thanks for reporting the bug, sending traces, and having patience.

Comment 39 Dusko Dobranic 2005-08-16 10:46:18 UTC
SE Linux disabled
kernel 2.6.12-1.1398_FC4

When I execute auditctl -D I get:

No rules
File system watches not supported

Comment 40 Tomek 2005-09-04 21:00:03 UTC

I have:

[root@ts ~]# uname -a
Linux ts #1 Sun Sep 4 21:09:20 CEST 2005 i686 i686 i386 GNU/Linux


[root@ts ~]# auditctl -D
Error receiving watch list (Invalid argument)
No rules
NLMSG_ERROR 22 (Invalid argument)
[root@ts ~]#


Comment 41 Steve Grubb 2005-09-05 12:29:45 UTC
Regarding comment #40, could you attach a strace of running "auditcl -D"? Thanks.

Comment 42 Tomek 2005-09-05 13:12:54 UTC
Created attachment 118470 [details]
strace of running "auditcl -D"

I attached strace a strace of running "auditcl -D"


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