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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
