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
