From nobody Fri Apr 1 13:26:26 2022 X-Original-To: freebsd-stable@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 E1B171A4C995 for ; Fri, 1 Apr 2022 13:36:26 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVLmT68bKz4mYX for ; Fri, 1 Apr 2022 13:36:25 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 231Da4fq018327 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 1 Apr 2022 15:36:05 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: (from uucp@localhost) by uucp.dinoex.sub.de (8.17.1/8.17.1/Submit) with UUCP id 231Da459018326; Fri, 1 Apr 2022 15:36:04 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.16.1/8.16.1) with ESMTP id 231DRwdG082466; Fri, 1 Apr 2022 15:27:58 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by gate.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 231DQQ1L082226 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 1 Apr 2022 15:26:26 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: (from peter@localhost) by gate.intra.daemon.contact (8.16.1/8.16.1/Submit) id 231DQQFE082225; Fri, 1 Apr 2022 15:26:26 +0200 (CEST) (envelope-from peter) Date: Fri, 1 Apr 2022 15:26:26 +0200 From: Peter To: Kevin Oberman Cc: "Bjoern A. Zeeb" , FreeBSD-STABLE Mailing List Subject: Re: Slow startup from D19488 (rtsol: sendmsg: Permission denied) Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [185.220.148.12]); Fri, 01 Apr 2022 15:36:07 +0200 (CEST) X-Rspamd-Queue-Id: 4KVLmT68bKz4mYX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=pmc@citylink.dinoex.sub.org X-Spamd-Result: default: False [-1.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[sub.org]; NEURAL_SPAM_SHORT(0.58)[0.576]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Mar 30, 2022 at 08:59:24PM -0700, Kevin Oberman wrote: ! > ! I am a bit puzzled as after two years you are the first one to report ! > ! that problem to my knowledge for either base system or jails. ! > ! > This is what greatly wonders me, too. So I was stronly thinking ! > that I am doing something wrong or unusual. But I cannot figure ! > it out, it just seems that the detrimental effect of the change ! > cannot be avoided (e.g. "service jail start" takes quite long now - ! > there's a lot of them). ! This may be irrelevant, but updating to the stable branch is not ! recommended as it is not regularly tested. Updating to 13.0-Release and ! then to stable is less likely to be problematic. Hi Kevin, (You are Kevin Oberman the network guru ?!?) You're essentially right, and I would normally agree. And it is not irrelevant, but then, it's apparently not related to this specific issue. The point is: I am not interested in 13.0. I am interested in 13.1. So I put up a pilot early, in order to report potential issues (as I reported here the issue with the fix for PR 76398). At that point this had to be stable/13. Then on saturday I tried to use fib, and I figured that fib is not fully implenented in 12.3, but apparently it is in 13. So I decided to give it a try and move my backbone to 13 - and to the same version that is already running on the pilot system, so that there is some base to compare things. Now there are issues - but it doesn't appear that these issues would be very different between stable/13 and releng/13.1. And -as can be read above- it neither looks like these issues would just disappear by themselves in the release, without someone looking for them. (The broken "ipfw fwd" is probably also present in 13.0 and will very likely still be present in 13.1 - and I don't believe much in testing because you can only test what you already expect to fail.) I am indeed pondering about the best approach. Over the last years I was only doing release upgrades (after I had run into ugly ZFS problems somewhere in Rel.10, caused by an intermediately broken Stable *and* broken memory chips). Now I am considering to do upgrades some 2-3 months ahead of the release, so if there are problems that hit here, there is a chance to spare the general public one or two troubles. cheerio, PMc