Re: security/py-fail2ban quits working after some hours

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Tue, 11 Oct 2022 15:20:08 UTC
Seems he hasn't rolled a new release. Bug like this should have 
precipitated a new dot release.

I'll keep monitoring his git repo. If there are any interesting commits, I 
may want to add a fail2ban-devel port tracking development. But so far it 
appears his repo has been inactive since 1.0.1 except for a testsuite 
bugfix and this bugfix.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0


In message <9sso211q-1r13-5702-s8rp-4306qq9q1q39@mx.roble.com>, Roger 
Marquis w
rites:
> Patch is working as intended here Cy.  Good catch and thanks!
>
> Roger Marquis
>
>
>
>
> > 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.
> >
> >
> >
> >