Date: Tue, 11 Oct 2022 08:20:08 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Roger Marquis <marquis@roble.com> Cc: freeBSD ports <freebsd-ports@FreeBSD.org>, Michael Grimm <trashcan@ellael.org>, "cy@freebsd.org" <cy@FreeBSD.org> Subject: Re: security/py-fail2ban quits working after some hours Message-ID: <20221011152008.A0F43C5@slippy.cwsent.com> In-Reply-To: <9sso211q-1r13-5702-s8rp-4306qq9q1q39@mx.roble.com> References: <6EF1B25D-3121-4FA1-BF47-DCE1FFD64A5E@ellael.org> <20221010204219.4A3ED19F@slippy.cwsent.com> <pqrnp6nq-7p8o-19o4-pq24-26p19qr733sn@mx.roble.com> <20221011042427.78E0BD1@slippy.cwsent.com> <9sso211q-1r13-5702-s8rp-4306qq9q1q39@mx.roble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20221011152008.A0F43C5>