Sorry for the late response.
The suggested solution:
logrotate configuration must run 'fail2ban-client set logtarget
/var/log/fail2ban.log' instead of 'invoke-rc.d --quiet fail2ban reload'
Seems to be working as well.
I think will stick with it (but keep the socket under /var/run).
Thanks a
Hi Karsten,
Thanks for the follow up... can't say that I am too happy to receive it
though ;)
So, you claim, that on 'reload' fail2ban still keeps the files open or
smth which forbids logrotate to complete the operation safely?
I guess the issue is with something else (i.e. not not-closed
btw -- does solution suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537773
helps to resolve your issue as well?
On Tue, 08 Sep 2009, Yaroslav Halchenko wrote:
Hi Karsten,
Thanks for the follow up... can't say that I am too happy to receive it
though ;)
--
We have troubles as well on etch and lenny (amd64).
Bug is not fixed in recent distribution - the logrotate script contains a
missconfiguration:
* for
fail2ban 0.7.5-2etch1:
change the following line in
/etc/logrotate.d/fail2ban
invoke-rc.d --quiet fail2ban reload /dev/null
Package: fail2ban
Version: 0.7.5-2
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
The logrotate script that ships with the fail2ban package stalls.
Preventing all other cron.daily scripts that are sorted after the
logrotate script to be not executed.
After restarting the
tags 434368 + moreinfo
thanks
please check if your issue is not related to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410077
please run fail2ban in verbose mode loglevel = 4 and email me
/var/log/fail2ban.log
On Mon, 23 Jul 2007, Alexander Dreweke wrote:
Package: fail2ban
Version:
please run fail2ban in verbose mode loglevel = 4 and email me
/var/log/fail2ban.log
I've attached the log with loglevel = 4. cron was able to complete the
fail2ban logrotate job successfully so there should not be any problems
in the log. I will mail you another file the moment I discover
7 matches
Mail list logo
