Hi Steve,
Thanks for the response.
> I went from using the standard CAPP.rules example file to the
> following audit.rules file:
This reduces what the kernel is doing. Does this also reduce the
number of
events hitting your audit logs?
Yes this did reduce the events hitting the logs quite considerably.
I wonder if you still see the leak if you load the rules but do not
start the
audit daemon? We need to see if its a kernel memory leak or user
space. I've
run valgrind against auditd and do not know of any leaks.
I loaded just the rules and left it overnight and it still looks fine.
size-32 3688 3808 32 119 1 : tunables 120
60 8 : slabdata 32 32 0
[root@blah ~]# auditctl -l
No rules
AUDIT_WATCH_LIST: dev=9:1, path=/etc, filterkey=ETC, perms=w, valid=0
AUDIT_WATCH_LIST: dev=9:1, path=/etc/sysconfig, filterkey=SYSCONFIG,
perms=w, valid=0
AUDIT_WATCH_LIST: dev=9:3, path=/caer/e/cnf, filterkey=DMS_CNF,
perms=w, valid=0
AUDIT_WATCH_LIST: dev=9:3, path=/caer/g/cnf, filterkey=GAS_CNF,
perms=w, valid=0
AUDIT_WATCH_LIST: dev=9:1, path=/bin/su, filterkey=SBIN, perms=x,
valid=0
>
> Whereas on a server not running the auditd daemon a cat /proc/
> slabinfo gives:
> After two minutes:
> size-32 3556 3808 32 119 1 : tunables 120
> 60 8 : slabdata 32 32 0
> After several hours:
> size-32 3601 3808 32 119 1 : tunables 120
> 60 8 : slabdata 32 32 0
But do you still have the CAPP rules loaded?
This was with no CAPP rules nor auditd running.
No one's reported such an issue...so no one's worked on it. The
first step is
determining if the problem is kernel or user space. Please load the
CAPP
rules without starting the audit daemon and see what that shows.
Thanks,
-Steve
I loaded the CAPP example rules (and auditd) and it appears to leak
very slowly. After a couple of days it's sitting at:
size-32 84728 84728 32 119 1 : tunables 120
60 8 : slabdata 712 712
We never saw the OOM killer in the six months that we ran with the
CAPP example rules.
When I use the cut down CAPP rules it will kill the box within about
2 days.
Regards,
Simon.