Re: security/py-fail2ban quits working after some hours
Date: Tue, 11 Oct 2022 09:04:56 UTC
Cy Schubert <Cy.Schubert@cschubert.com> wrote > In message <pqrnp6nq-7p8o-19o4-pq24-26p19qr733sn@mx.roble.com>, Roger > Marquis w > rites: >> Cy Schubert wrote: >>> Michael Grimm writes: >>>> this is a recent stable/13-n252672-2bd3dbe3dd6 running = >>>> py39-fail2ban-1.0.1_2 and python39-3.9.14 >>>> I have been running fail2ban for years now, but immediately after = >>>> upgrading py39-fail2ban fron 0.11.2 to 1.0.1 the fail2ban-server will = >>>> end up as a runaway process consuming all CPU time. This happens between = >>>> 4 to 24 hours after initial fail2ban-server startup. >> >> Am running fail2ban-1.0.1_2 and python38-3.8.14 did have a similar >> startup issue. Could not use the 'service' command and had to restort >> to 'kill -9' to stop. Fix for that was to delete /var/{run,db}/fail2ban/* >> and restart. >> >> Still seeing relatively high CPU utilization compared to the previous >> version though it rotates cores quickly. >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 67125 root 17 20 0 74M 12M uwait 8 23.7H 102.94% python3.8 >> >> Voluntary Context SWitches seem high compared to other processes though >> have no previous benchmark to compare. >> >> PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND >> 67125 root 5907 23 0 0 0 0 0.00% python3.8 >> >> Only reading from 5 logfiles; kernel is 12.3-RELEASE-p7; fail2ban built >> from ports; truss reporting mostly "ERR#60 'Operation timed out'"... >> >> Roger Marquis >> > > I've been able to reproduce the problem here. Please try the attached patch > obtained from our upstream. It fixes a dovecot regression that crept into > the latest release. Yes, I am running dovecot jails at both servers. Like Roger, truss reports "ERR#60 'Operation timed out'", only. I did apply your patch, and both instances are up running. I will report back. But that will take some hours to observe. Thanks for your patch, highly appreciated, Michael