Re: Log rotation and client disconnects
On Monday, August 09, 2010 12:59:50 pm rshaw1(a)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