Log rotation and client disconnects

[Steve Grubb]

On Monday, August 09, 2010 12:59:50 pm rshaw1 at umbc.edu wrote:
> I had been using logrotate to rotate the logs (in order to get them named
> with a date extension, bzipped a day after being rotated, etc.)  I thought
> that restarting the daemons each night might be causing issues with many
> clients trying to reconnect at once, so I tried using copytruncate in
> order to avoid restarting.  This appears to make auditd crash, so I'm
> looking at using its built-in rotation.

Yes, this is the preferred way.


> However, "service auditd rotate" does not do anything.

It should. I just double-checked the code and I can't see how it doesn't work 
without writing something to syslog on error.


> The man page says this "will consult the max_log_size_action to see if it
> should keep the logs or not", but I'm not sure what that means;

It means that if you set the action to rotate, then it will delete any log 
that results in a number higher than the num_logs.


> there is "max_log_file_action", which I have set to "ignore" as the FAQ
> specifies.

That means do nothing when the size of the log file exceeds max_log_file in 
megabytes. But this has no effect on rotation by the "service auditd rotate" 
technique. Its working like its supposed to on my system.

 
> I'm also having separate issues with some clients disconnecting from the
> server, retrying twice in about a 40 second interval, and then giving up.
> The server isn't going down, and this isn't even happening at the same
> time I was restarting auditd. 

Anything written to syslog on either end?


> I would really like the clients to make more of an effort at reconnecting.  I
> have the configuration options set like so on the clients, but maybe I'm
> misunderstanding what they do:
> 
> network_retry_time = 30

^^ time to delay in seconds between retries

> max_tries_per_record = 60

How many time to retry

> max_time_per_record = 5

Maximum time before doing the network failure action.

> remote_ending_action = reconnect
> 
> Finally, if anyone has any recommendations for setting tcp_listen_queue on
> the server (I'm not sure if this is supposed to indicate a number of audit
> messages or clients) and queue_depth on the clients when using a few
> hundred clients, that would be great.

If you have a few hundred clients, you will want to set the number higher. 
This is the queue size in the kernel for pending connections. How high ? 
Experiment. But 25 would be a good start and go higher.

-Steve