From nobody Thu Feb 20 14:10:49 2025 X-Original-To: freebsd-current@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 4YzFYH4sx6z5nx7B for ; Thu, 20 Feb 2025 14:11:15 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4YzFYF1Qdnz3T3b for ; Thu, 20 Feb 2025 14:11:12 +0000 (UTC) (envelope-from janm@transactionware.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of janm@transactionware.com designates 203.14.245.7 as permitted sender) smtp.mailfrom=janm@transactionware.com Received: (qmail 9483 invoked by uid 907); 20 Feb 2025 14:11:04 -0000 Received: from i5E864487.versanet.de (HELO smtpclient.apple) (94.134.68.135) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Fri, 21 Feb 2025 01:11:04 +1100 Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: RFC: mount_nfs failure due to dns not running yet From: Jan Martin Mikkelsen In-Reply-To: Date: Thu, 20 Feb 2025 15:10:49 +0100 Cc: FreeBSD CURRENT , Gleb Smirnoff Content-Transfer-Encoding: quoted-printable Message-Id: <86DA09CB-C743-498A-BD6D-8A36D247878F@transactionware.com> References: To: Rick Macklem X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spamd-Result: default: False [-1.82 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:203.14.245.0/24]; NEURAL_HAM_SHORT(-0.12)[-0.124]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[transactionware.com]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4YzFYF1Qdnz3T3b X-Spamd-Bar: - Hi, DNS resolvers can fail transiently, as can UDP. At least some retries = seem to make sense. (I don=E2=80=99t use NFS; this is a general comment.) Regards, Jan M. > On 19. Feb 2025, at 23:40, Rick Macklem = wrote: >=20 > Hi, >=20 > The subject line basically describes the problem glebius@ > ran into. When doing an NFS mount in /etc/fstab, it failed > since the DNS service was not yet working and, as such, > the DNS lookup of the server fqdn failed, causing the mount > to fail. Note that this behaviour has existed for decades. >=20 > He feels this is a bug and that mount_nfs(8) should retry > getaddrinfo(3) calls until success, instead of failing the > mount when the first attempt fails. > The problem with just retrying getaddrinfo(3) is that it > could retry forever for simple failures like a typo in the > server fqdn. > I can see several ways this can be handled and would > like feedback from others w.r.t. these alternatives. >=20 > 1) Simply document this case and encourage use of > host names in /etc/hosts for NFS servers along with > specifying use of file before dns in nsswitch.conf. > Doing this results in the mounts working whether or > not DNS is working. >=20 > 2) Call it a bug and patch mount_nfs(8) to retry getaddrinfo(3) > until it succeeds. (I feel this would be a POLA violation, > given that the current behaviour has existed for decades > and for simple cases where the fqdn will never resolve > the behaviour would be to hang at the mount attempt > during boot unless "bg" is specified for the /etc/fstab entry.) >=20 > 3) Add a new NFS mount option "retrydns=3D", which would enable > retries of getaddrinfo(3). This would avoid any POLA violation and > would allow for a convenient way to document the behaviour in > "man mount_nfs". >=20 > 4) ??? >=20 > So, what do you think is the preferred change? >=20 > rick > ps: I looked and the return value from getaddrinfo(3) does not > appear to be useful to discern the case of "DNS service not > running yet". (I think it replies EAI_FAIL for this case.) >=20