> On 22 Dec 2021, at 07:51, Alexander Bochmann <ab@???> wrote:
>
> 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.

I didn’t look to see if there were OOM issues but I did notice fail2ban not upgrading due to an existing process still running. For whatever reason, the upgrade scripts in the chimaera/bullseye .deb weren’t handling this properly.

I now just stop the fail2ban process on Beowulf before running the upgrade to chimaera, and it seems to work without failing.