From owner-freebsd-bugs@freebsd.org Thu Sep 6 20:00:58 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7F6CFE4284 for ; Thu, 6 Sep 2018 20:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 52D0F89FCA for ; Thu, 6 Sep 2018 20:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 180A1FE4282; Thu, 6 Sep 2018 20:00:58 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA8BBFE4281 for ; Thu, 6 Sep 2018 20:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FD3789FC3 for ; Thu, 6 Sep 2018 20:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B5B581578 for ; Thu, 6 Sep 2018 20:00:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w86K0uhj049935 for ; Thu, 6 Sep 2018 20:00:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w86K0uht049931 for bugs@FreeBSD.org; Thu, 6 Sep 2018 20:00:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 231193] ntpd peers stuck in INIT status when using local named Date: Thu, 06 Sep 2018 20:00:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ian@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 20:00:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231193 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |ian@FreeBSD.org Status|New |Open --- Comment #2 from Ian Lepore --- (In reply to ml from comment #0) It's not clear to me that it's ntpd having trouble resolving those names. = The name resolution errors in the log are from ntpdate, not ntpd. When the pee= rs are stuck in INIT state, what is the output from "ntpq -np"? That will show for sure whether the addresses are resolved. That ntpq output looks to me = more like the names are resolved but UDP packets to or from port 123 are being blocked somehow. Oh, hmm... after looking again it looks like the names may not be resolved = when ntpd processes the config file (I just noticed the errors about restrict), = but then they do resolve by time the peer configuration happens, so you end up = with resolved peers who can't communicate because the restrict statements that w= ould have allowed communications with them never got processed. I think waiting for named to be ready is the only viable fix, and I agree w= ith you that the ability to have an optional timeout for that wait is also important. IMO, dougb was wrong to reject the changes in bug 144400, and I think I'll look into re-opening that and fixing it. But I can't make any promises that it'll get into 12.0-RELEASE, I'm really busy these days. --=20 You are receiving this mail because: You are the assignee for the bug.=