From owner-freebsd-ports@freebsd.org Sat May 2 16:53:22 2020 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 48D202D458A for ; Sat, 2 May 2020 16:53:22 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:510a::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.burggraben.net", Issuer "Christoph Moench-Tegeder" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49DwDK4V4Xz4NyY for ; Sat, 2 May 2020 16:53:21 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from elch.exwg.net (elch.exwg.net [IPv6:2001:470:7120:1:127b:44ff:fe4f:148d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elch.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by smtp.burggraben.net (Postfix) with ESMTPS id BF8F0C00309 for ; Sat, 2 May 2020 18:53:18 +0200 (CEST) Received: by elch.exwg.net (Postfix, from userid 1000) id 701F1139858; Sat, 2 May 2020 18:53:18 +0200 (CEST) Date: Sat, 2 May 2020 18:53:18 +0200 From: Christoph Moench-Tegeder To: freebsd-ports@freebsd.org Subject: Re: Bind 9.16 port error still lingers Message-ID: <20200502165318.GB4453@elch.exwg.net> References: <20200502140501.GA16385@doctor.nl2k.ab.ca> <20200502143210.GA4453@elch.exwg.net> <20200502151636.GA22397@doctor.nl2k.ab.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200502151636.GA22397@doctor.nl2k.ab.ca> User-Agent: Mutt/1.13.5 (2020-03-28) X-Rspamd-Queue-Id: 49DwDK4V4Xz4NyY X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of cmt@burggraben.net designates 2a01:4f8:140:510a::3 as permitted sender) smtp.mailfrom=cmt@burggraben.net X-Spamd-Result: default: False [-5.25 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:140:510a::3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[burggraben.net]; RCVD_IN_DNSWL_MED(-0.20)[3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.1.5.0.4.1.0.8.f.4.0.1.0.a.2.list.dnswl.org : 127.0.6.2]; IP_SCORE(-2.75)[ip: (-9.53), ipnet: 2a01:4f8::/29(-2.66), asn: 24940(-1.52), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 16:53:22 -0000 ## The Doctor via freebsd-ports (freebsd-ports@freebsd.org): > > > Subject: Bind 9.16 port error still lingers > > > > "Still"? You seemed to imply that there was a known problem in our bind port. While I doubt the existence of a problem with this severity (at least my and other people's bind instances are happily serving away), a pointer to that previous description could still be quite helpful. > > > May 1 21:29:02 gallifrey named[90441]: parser.c:950: REQUIRE(obj != ((void *)0) && obj->type->rep == &cfg_rep_uint32) failed, back trace > > > > Some (configuration) value should be an integer, but isn't. Have you checked your configuration for that type of problem? Even a simple named-checkconf could go a long way here. > and ls -Fail /var/run/named.pid > > -rw-r--r-- 1 root wheel 6 May 1 21:38 /var/run/named.pid And that's still not the default location, and again the pid file was created via the workaround code - else that file would have been written as user "bind" - which only works at the default location, which is why we have that default location. Your configuration differs from the default configuration in more than "local addresses and zones", but you have given neither details nor rationale on your changes - all we have is some deductions from error messages. That might make for a good detective story, but does not really expedite technical analysis. Regards, Christoph -- Spare Space