> On 22 Dec 2021, at 07:51, Alexander Bochmann 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.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
