Date: Mon, 10 Oct 2022 13:42:19 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Michael Grimm <trashcan@ellael.org> Cc: freeBSD ports <freebsd-ports@FreeBSD.org>, "cy@freebsd.org" <cy@FreeBSD.org> Subject: Re: security/py-fail2ban quits working after some hours Message-ID: <20221010204219.4A3ED19F@slippy.cwsent.com> In-Reply-To: <6EF1B25D-3121-4FA1-BF47-DCE1FFD64A5E@ellael.org> References: <6EF1B25D-3121-4FA1-BF47-DCE1FFD64A5E@ellael.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <6EF1B25D-3121-4FA1-BF47-DCE1FFD64A5E@ellael.org>, Michael Grimm wri tes: > [cc's to maintainer] > > Hi, > > 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. > > I have recompiled world, kernel and all ports, but I to no avail. I am = > able to reproduce this behaviour on two different host running the same = > OS et al. > > > After becoming a runaway process: > =20 > root> /usr/local/etc/rc.d/fail2ban status > fail2ban is running as pid 26487. > > root> ps Af | grep fail2ban > 26487 - S 545:40.61 /usr/local/bin/python3.9 = > /usr/local/bin/fail2ban-server --async -b -s = > /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid = > --loglevel INFO --logtarget SYSLOG --syslogsocket auto The only difference between mine is --logtarget is a file. > > root> /usr/local/etc/rc.d/fail2ban stop > ^C > 2022-10-08 09:29:45,451 fail2ban [1447]: WARNING = > Caught signal 2. Exiting > > root> kill -9 26487 > > root> /usr/local/etc/rc.d/fail2ban start > 2022-10-08 09:30:30,776 fail2ban [1609]: ERROR = > Fail2ban seems to be in unexpected state (not running but the socket = > exists) > > root> la /var/run/fail2ban/* > -rw------- 1 root wheel uarch 6 Oct 7 21:26 = > /var/run/fail2ban/fail2ban.pid > srwx------ 1 root wheel uarch 0 Oct 7 21:26 = > /var/run/fail2ban/fail2ban.sock > > root> rm /var/run/fail2ban/* > > root> /usr/local/etc/rc.d/fail2ban start > Server ready > > > So, whenever the server becomes a runaway process, it can only restarted = > by killing it hard, and after removing both pid and sock files. This isn't enough information to diagnose the problem. See below. > > Has anyone else run into this issue, or am I the only one so far? = > Couldn't find anything according this issue in the bugtrackers and on = > Google. I've been running this version for over a week without issue. > > > > > BTW: One glitch in fail2ban.conf file: > > # Option: allowipv6 > # Notes.: Allows IPv6 interface: > # Default: auto > # Values: [ auto yes (on, true, 1) no (off, false, 0) ] Default: = > auto > #allowipv6 =3D auto This won't cause looping. > > This will result in a warning at start time: > > 2022-10-08 09:30:51,520 fail2ban.configreader [1633]: WARNING = > 'allowipv6' not defined in 'Definition'. Using default one: 'auto' > > After activating this entry to "allowipv6 =3D auto" those warnings = > disappear. Can you answer a few questions, please? 1. What does uname -a say? 2. Was fail2ban built from ports or did you pkg upgrade? 3. What other ports/packages are installed? 4. Which filters are you using? Have you modified any? Or have you written your own? 5. Which actions are you using? Have you modified them? Or have you written your own? 6. When fail2ban loops, instead of simply killing it, run truss. You can do this by: truss -faeD -o fail2ban.truss -p THE_TRUSS_PID -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20221010204219.4A3ED19F>