[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Attempting to deal with " audispd: queue is full - dropping event" messages



On Wednesday, October 06, 2010 08:50:36 pm Jim Richard wrote:
> I'm getting several hundred of these each day on my servers. I'm using
> remote logging to a central sever via the audisp-remote plugin. I've seen
> recommendations to up the following setting in audispd.conf to help
> minimize these errors:
> 
> priority_boost = 8

You can go higher, too.


> This seems to raise the priority of the audispd daemon, but I'm also using
> audisp-remote to a central log servers. This setting doesn't seem to
> effect the priority of the remote plugin, as evidenced for the following
> output from the top command:

The child processes inherit the priority of the audit daemon. This is because 
you don't want the plugins fighting the parent process for time slots. The main 
issue is communication between auditd and audispd.

 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 13498 root      11  -4 10096  844  684 S  0.0  0.0   0:00.01 audisp-remote
> 13497 root       3 -12 16268  768  624 S  0.0  0.0   0:00.00 audispd
> 13495 root      11  -4 27352  868  588 S  0.0  0.0   0:00.00 auditd
> 
> For the priority boost to be fully effective wouldn't it have to apply to
> the plugins as well?  Is there a way to boost priority on audisp-remote?
> If not, should there be a way to do this or should it be automatic?

Yes, boost auditd's priority if you really want to.

 
> Also are there any other settings that can be made to minimize/eliminate
> dropped events from audispd? I'm curious about the following:
> 
> *       Audispd.conf: q_depth
> *       Audisp-remote.conf: queue_depth

The warning message you are getting is from audispd. You can increase its 
queue and priority.

 
> How do these two relate to each other, should they be the same, or some
> specific ratio... etc?

The audisp-remote queue is based on how many events you want it to queue for 
network latency or server reboots. You can make it as big as you want.

 
> Thanks in advance for any suggestions on this.
 
There is no hard and fast rule. It depends on your audit rules, system 
behavior, and network traffic.

-Steve


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]