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
next prev parent 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).