Hi Kris, What does your stress.conf file look like? I'm curious because on my system, I can lose audit records without much load at all, but I'm running the default auditd.conf. -- ljk

I'm using the 0.7.3-1 user-space tools and the .28 kernel. I'm using the default auditd.conf file, which has priority_boost = 3. I was doing something a bit unusual. I was running some manual tests with audit rules that audit all syscalls with my uid and it was working fine until I forgot to turn it off before locking my X session. At that point, the screen saver did stuff like close every possible file descriptor, as far as I can tell from the log, so between locking the session and restarting it, I lost hundreds of records. I can usually, but not always, reproduce record loss with a program similar to one of Kris' tests, but with fewer than 200 iterations. I haven't tried fooling with the auditd.conf parameters yet, so I was curious about the stress.conf file. -- ljk

On Thursday 05 May 2005 17:34, Chris Wright wrote: <snip> FWIW, I ran this for hours and had no lost messages. I tested with a backlog of 1024 & priority_boost of 3. -Steve

backlog How do you set backlog? Is the default 64? For the evaluation should our configuration script change it to 1024? Thanks!

On Friday 06 May 2005 12:06, Kris Wilson wrote: -b 1024 in /etc/audit.rules Yes. That depends. If you are testing what actions occur when messages are dropped, you want to set it lower. For normal operation, you will want to set it higher. I was thinking that we need some kind of load test to tune the number with. The combination of priority & backlog will need to be set depending on: expected load, audit rules, the speed of the CPU, and the slowness of the disk. During normal operations, events pile up. When the audit daemon gets its time slice, it drains the queue quickly. Then events pile up again. Lengthening the queue lets you run the system through bursts of activity without losing a record. The fundamental question is how long should I make the queue? The answer I think is based on how often the audit daemon runs and how many events can pile up in the interim. The audit daemon must get enough time slices that the queue is sitting at 0 nearly anytime you check. If the backlog value starts creeping up, the audit daemon is losing the race and needs more priority. I almost think this needs a utility to help tune it. If a system has a fast CPU, it could generate more events than a slower CPU. If the disk is slow, we can't dispatch events as fast and that needs to be accounted for. -Steve

linux-audit-bounces(a)redhat.com wrote on 05/05/2005 04:06:56 PM: # # This file controls the configuration of the audit daemon # log_file = /var/log/audit/audit.log log_format = RAW priority_boost = 3 flush = DATA freq = 0 num_logs = 3 max_log_file = 4 max_log_file_action = ROTATE space_left = 75 space_left_action = SYSLOG admin_space_left = 50 admin_space_left_action = SUSPEND disk_full_action = SUSPEND