Hello,
I won't follow your suggestion to report it upstream. I think he does the right
thing
when fail2ban-client flushlogs exits with an error code when fail2ban is
running.
That said, I think logrotate shouldn't fail either in these circumstances. It
could be
that the administrator stopped fail2ban for his own reasons, or that he just
installed
the package and still hasn't ran it at all. It could also be there is a problem
and
fail2ban stopped running without any one aware of that. And there could be other
circumstances why fail2ban is not running. Still, I think the right action, if
at all, to
make someone aware of it is not by creating logrotate failures.
On Tuesday, April 14, 2020, 10:45:15 AM GMT+1, Sylvestre Ledru
<sylves...@debian.org> wrote:
Hello
Thanks for your patch!
Le 14/04/2020 à 11:30, Ron Varburg a écrit :
> Package: fail2ban
> Version: 0.10.2-2.1
> Severity: normal
> Tags: patch
>
> The following patch:
> 1. Prevents logrotate failures when fail2ban doesn't run for any reason.
> When fail2ban isn't running, fail2ban-client flushlogs exits with an
>error
> code. I think announcing fail2ban isn't running should not be made by
> making logrotate to fail.
This should be fixed upstream in "fail2ban-client flushlogs" I think.
Could you please report an issue there?
> 2. Doesn't rotate empty log files.
agreed & pushed. thanks
Cheers,
Sylvestre
