All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.