From nobody Thu Jan 5 14:22:03 2023 X-Original-To: freebsd-arm@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 4NnpZ35NC1z2qvWF for ; Thu, 5 Jan 2023 14:21:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NnpZ2505Gz3s9f for ; Thu, 5 Jan 2023 14:21:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 305EM3kp011638 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 5 Jan 2023 06:22:03 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 305EM3Qf011637; Thu, 5 Jan 2023 06:22:03 -0800 (PST) (envelope-from fbsd) Date: Thu, 5 Jan 2023 06:22:03 -0800 From: bob prohaska To: John F Carr Cc: freebsd-arm@freebsd.org Subject: Re: Named reporting port in use on 12.4-STABLE r372838 GENERIC arm Message-ID: <20230105142203.GA11502@www.zefox.net> References: <20230105051849.GA5563@www.zefox.net> <8072B9BF-71E4-4385-8426-1808D72AD47E@mit.edu> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8072B9BF-71E4-4385-8426-1808D72AD47E@mit.edu> X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4NnpZ2505Gz3s9f X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Thu, Jan 05, 2023 at 09:19:58AM +0000, John F Carr wrote: > Do you have both unbound and named enabled? > Certainly not intentionally, and seemingly not at all: root@ns1:/usr/ports # ps -aux | grep -i unbound root 7597 0.0 0.2 4788 1884 0 S+ 05:44 0:00.01 grep -i unbound while /etc/defaults/rc.conf contains local_unbound_enable="NO" # Local caching resolver local_unbound_tls="NO" # Use DNS over TLS with no reference to unbound in /etc/rc.conf . Perhaps the error message was spurious, though it certainly seemed that named wasn't working immediately after reboot last night when tested with nslookup. Rndc status now reports the server is up and running, nslookup gets answers. Named seems to be working, at least for now. Maybe I'm somehow starting named twice and only noticed the fact yesterday. Thanks for writing! bob prohaska > > On Jan 5, 2023, at 00:18, bob prohaska wrote: > > > > After an upgrade to 12.4-STABLE r372838 GENERIC arm on a Pi2 (armv7) > > BIND 9.16.1 (Stable Release) fails on start with > > Jan 4 20:41:25 ns1 named[973]: creating TCP socket: address in use > > Jan 4 20:41:25 ns1 syslogd: last message repeated 2 times > > Jan 4 20:41:25 ns1 named[973]: unable to listen on any configured interfaces > > Jan 4 20:41:25 ns1 named[973]: loading configuration: failure > > Jan 4 20:41:25 ns1 named[973]: exiting (due to fatal error) > > > > Apart from the OS upgrade nothing was changed and it had been > > working flawlessly for about six months. Re-using the old kernel > > didn't fix it, has something in userland changed? A slave machine > > updated yesterday without trouble so I thought it was safe to > > update the master. > > > > Thanks for reading, any hints appreciated! > > > > bob prohaska > > > > > >