Date: Tue, 11 Oct 2022 11:04:56 +0200 From: Michael Grimm <trashcan@ellael.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Roger Marquis <marquis@roble.com>, freeBSD ports <freebsd-ports@FreeBSD.org>, "cy@freebsd.org" <cy@FreeBSD.org> Subject: Re: security/py-fail2ban quits working after some hours Message-ID: <BE17DDA9-FBA4-4EA5-B685-6D5E9DEB39D1@ellael.org> In-Reply-To: <20221011042427.78E0BD1@slippy.cwsent.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>
next in thread | previous in thread | raw e-mail | index | archive | help
Cy Schubert <Cy.Schubert@cschubert.com> wrote
> In message <pqrnp6nq-7p8o-19o4-pq24-26p19qr733sn@mx.roble.com>, Roger=20=
> Marquis w
> rites:
>> Cy Schubert wrote:
>>> Michael Grimm writes:
>>>> this is a recent stable/13-n252672-2bd3dbe3dd6 running =3D
>>>> py39-fail2ban-1.0.1_2 and python39-3.9.14
>>>> I have been running fail2ban for years now, but immediately after =3D=
>>>> upgrading py39-fail2ban fron 0.11.2 to 1.0.1 the fail2ban-server =
will =3D
>>>> end up as a runaway process consuming all CPU time. This happens =
between =3D
>>>> 4 to 24 hours after initial fail2ban-server startup.
>>=20
>> 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.
>>=20
>> Still seeing relatively high CPU utilization compared to the previous
>> version though it rotates cores quickly.
>>=20
>> 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
>>=20
>> Voluntary Context SWitches seem high compared to other processes =
though
>> have no previous benchmark to compare.
>>=20
>> PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
>> 67125 root 5907 23 0 0 0 0 0.00% python3.8
>>=20
>> Only reading from 5 logfiles; kernel is 12.3-RELEASE-p7; fail2ban =
built
>> from ports; truss reporting mostly "ERR#60 'Operation timed out'"...
>>=20
>> Roger Marquis
>>=20
>=20
> I've been able to reproduce the problem here. Please try the attached =
patch=20
> obtained from our upstream. It fixes a dovecot regression that crept =
into=20
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE17DDA9-FBA4-4EA5-B685-6D5E9DEB39D1>