From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Log rotation and client disconnects Date: Thu, 12 Aug 2010 10:25:59 -0400 Message-ID: <201008121025.59525.sgrubb@redhat.com> References: <56567.128.63.24.134.1281373190.squirrel@webmail.umbc.edu> <201008091353.32210.sgrubb@redhat.com> <58805.128.63.24.134.1281621749.squirrel@webmail.umbc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <58805.128.63.24.134.1281621749.squirrel@webmail.umbc.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday, August 12, 2010 10:02:29 am rshaw1@umbc.edu wrote: > I've discovered the issue since I sent it, anyway. If num_logs is set to > 0, auditd will ignore explicit requests to rotate the logs. I guess this > may be intentional, but it's unfortunate as num_logs caps at 99 and I need > to keep 365 of them. Have you looked at the keep_logs option for max_log_file_action? > I suppose that since I'll have to rename and bzip > them anyway, I may as well just move them to another location (maybe > /var/log/audit/archive) so that auditd doesn't "see" them, unless there's > a better way to do this. Yes, you should archive them away since by being in /var/log/audit, they are used in calculating the log space left. > I'm still not sure what to do about the disconnection issues (although > hopefully those will be very infrequent once I'm no longer restarting any > of the daemons). If a client does lose the connection to the server for a > while though (say, an hour-long network outage for networking upgrades), > I'd like to be able to tell them to try reconnecting periodically, and the > combination of network_retry_time and max_tries_per_record doesn't seem to > be the way to do that. > > Other than checking the logs, is there a way to determine whether or not a > running audispd is connected to the remote server? It logs this. Also I suppose you could peek into its open descriptors with lsof or just checking in /proc. -Steve