Your message dated Sun, 15 Mar 2020 16:28:33 +0100
with message-id <[email protected]>
and subject line fixed - ever-growing fail2ban sqlite database
has caused the Debian Bug report #933749,
regarding fail2ban: ever-growing fail2ban sqlite database
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
933749: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933749
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: fail2ban
Version: 0.10.2-2.1
Severity: serious
Justification: filing up filesystem, slow startup

Hi,

I've noticed this on both stretch and buster hosts with the default
configuration: the database (/var/lib/fail2ban/fail2ban.sqlite3) doesn't
seem to get any kind of clean-up. I'm seeing this at the moment on those
two internet-connected hosts:

    626M /var/lib/fail2ban/fail2ban.sqlite3
    940M /var/lib/fail2ban/fail2ban.sqlite3

Toying with sqlite3 and a "select * from bans limit 1;", I'm seeing:

    sshd|ANO.NYM.IZ.ED|1519714548|{"matches": ["Feb 27 07:46:29 […]
    sshd|ANO.NYM.IZ.ED|1520144221|{"matches": ["Mar  4 07:16:36 […]

(I'm not even sure which year those entries come from…)

The only thing that seems related returns:

    Current database purge age is:
    `- 86400seconds

which matches this in /etc/fail2ban/fail2ban.conf:

    # Options: dbpurgeage
    # Notes.: Sets age at which bans should be purged from the database
    # Values: [ SECONDS ] Default: 86400 (24hours)
    dbpurgeage = 1d

and I'm not sure it's taken into account. Or whether that's meant to
control that the database grows forever.

A cheap workaround might be to switch the dbfile setting to:

    dbfile = :memory:

but having to do that seems very wong.


Looking around in the BTS, #823892 and #898536 seemed related but they
were closed already (with inappropriate versions since the BTS doesn't
know about backports anyway?)

Please let me know if I can help debug this further.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

--- End Message ---
--- Begin Message ---
fixed 933749 0.11.1-1
thanks

Hopefully fixed, please reopen if it isn't :)

S

--- End Message ---
_______________________________________________
Python-modules-team mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Reply via email to