> On 22 Dec 2021, at 07:51, Alexander Bochmann <a...@lists.gxis.de> 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
