From nobody Mon Oct 10 14:18:46 2022 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MmLcx1g98z4fWN8 for ; Mon, 10 Oct 2022 14:18:57 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [IPv6:2001:41d0:302:1100::1499]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MmLcw20RQz42rG; Mon, 10 Oct 2022 14:18:56 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (p200300fb4F008301Fc11FB141a574Da8.dip0.t-ipconnect.de [IPv6:2003:fb:4f00:8301:fc11:fb14:1a57:4da8]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 4MmLcl0vhkz1Bxx; Mon, 10 Oct 2022 16:18:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1665411527; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=aIBgLLLBC7woceODiqzDW9/j/4isO9nZMkHijSHUBdw=; b=yw3Q/y87RbQ/s2RZ1XtO1rcEAzUu8runr9eGIqlhSqmT+n38d4qWA+HpjFS4mYg7xrg/Ze 15vhXuwlVm+jmYbCH3GC1+8mwGPAJLVo2ahqHUsdMIQvVD0qXvvY3rbFozVY2u+dxN+9D+ p9IHEepoJO5hfpaJ2xAJcz8aANSTnlSHtnvSd5HDAGYtnJdf8LSPhrdmtO+zHYtSJFKjp/ 17lB2gwRfQvyvswH2UggPBOGh5fBR5HSCUtOz+OvHTza2gCFL+kBFrYBPfJM42gqhiJV9L rGR3I403/BPe31srNveKWUW5Da+FzddmsvsL3j9wjTKMtmQaoVYUACyxRNgZZA== From: Michael Grimm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: security/py-fail2ban quits working after some hours Message-Id: <6EF1B25D-3121-4FA1-BF47-DCE1FFD64A5E@ellael.org> Date: Mon, 10 Oct 2022 16:18:46 +0200 Cc: "cy@freebsd.org" To: freeBSD ports X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MmLcw20RQz42rG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ellael.org header.s=dkim header.b="yw3Q/y87"; dmarc=pass (policy=quarantine) header.from=ellael.org; spf=pass (mx1.freebsd.org: domain of trashcan@ellael.org designates 2001:41d0:302:1100::1499 as permitted sender) smtp.mailfrom=trashcan@ellael.org X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:302:1100::1499]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MLMMJ_DEST(0.00)[freebsd-ports@FreeBSD.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[ellael.org:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N [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 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. 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. 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 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. Regards, Michael