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

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.
>
>
>
>