fail2ban vs. logrotate

Mikkel L. Ellertson mellertson at
Tue Oct 25 15:12:42 UTC 2011

Hash: SHA1

On 10/25/2011 09:07 AM, Andre Speelmans wrote:
>> I was referring to the fail2ban RPM. This has to be a problem for
>> just about any installation that uses logrotate.
> Most daemons seem to use their own logfile and therefore can use their
> own logrotate configuration script in /etc/logrotate.d.
> But /var/log/secure is not handled by a specific daemon and thus is
> taken care of in the standard logrotate configuration. I don't know
> what effects it would give if you try to override it in a more
> specific configuration script. Might even not be possible. Or perhaps
> it is, hehe.
It is handled by syslogd.

> Anyway I think that when you depend on /var/log/secure (or any generic
> logfile), you can't do anything, except informing the users to change
> their configuration.
> To that extent you can either make it copy-truncate or add a
> postrotate script to restart/reload fail2ban.
It looks like you would have to modify the syslog logrotate script
and add a second command in the postrotate section after it restarts
syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?

- -- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
Version: GnuPG v1.4.11 (GNU/Linux)


More information about the users mailing list