Hi -

this is not a Devuan-specific problem, since I've also had it
happen when upgrading a Debian system:

During the dist-upgrade process, fail2ban is restarted and
then tries to do something with the previous sqlite database
that's stored in /var/lib/fail2ban/fail2ban.sqlite3 by default.

While working on the db, the fail2ban python3 process eats
up all available memory, and gets killed by the oom killer,
leaving behind a timestamped copy of the sqlite file. Depending
on the size of the database, this cycle repeats quickly, using
up (all) disk space on the way. The problem can be solved by
just removing the old database file and restarting fail2ban.

Did this hit anyone else? I haven't seen it mentioned
anywhere, but I've run into this several times now.

Alex.