linux-audit.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: Log rotation and client disconnects
Date: Mon, 9 Aug 2010 13:53:31 -0400	[thread overview]
Message-ID: <201008091353.32210.sgrubb@redhat.com> (raw)
In-Reply-To: <56567.128.63.24.134.1281373190.squirrel@webmail.umbc.edu>

On Monday, August 09, 2010 12:59:50 pm rshaw1@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

  reply	other threads:[~2010-08-09 17:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-09 16:59 Log rotation and client disconnects rshaw1
2010-08-09 17:53 ` Steve Grubb [this message]
2010-08-12 14:02   ` rshaw1
2010-08-12 14:25     ` Steve Grubb
2010-08-12 15:16       ` rshaw1
2010-08-12 15:57         ` LC Bruzenak
2010-08-13 15:06           ` rshaw1
2010-08-13 15:38             ` LC Bruzenak
2010-08-12 14:31     ` LC Bruzenak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201008091353.32210.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).