From nobody Mon Feb 24 02:54:23 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 4Z1QLV2h6yz5pWdW for ; Mon, 24 Feb 2025 02:54:26 +0000 (UTC) (envelope-from bsd.lists@h8spam.org) Received: from mx1.wiredblade.com (mx1.wiredblade.com [162.216.242.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z1QLT5S9Gz41gr for ; Mon, 24 Feb 2025 02:54:25 +0000 (UTC) (envelope-from bsd.lists@h8spam.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd.lists@h8spam.org has no SPF policy when checking 162.216.242.38) smtp.mailfrom=bsd.lists@h8spam.org Received: from webmail.dynu.com (webmail.dynu.com [162.216.242.204]) by mx1.wiredblade.com with ESMTPA ; Mon, 24 Feb 2025 02:54:23 +0000 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 Date: Mon, 24 Feb 2025 02:54:23 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.16.0 From: "Chris" Message-ID: <4f09507d6ddba4979a418e7f30f1f94a@h8spam.org> Subject: Re: RFC: mount_nfs failure due to dns not running yet To: "Rick Macklem" , "FreeBSD CURRENT" Cc: "Gleb Smirnoff" In-Reply-To: References: X-Originating-IP: 24.113.41.88 X-Spamd-Result: default: False [-2.89 / 15.00]; AUTH_NA(1.00)[]; RBL_SENDERSCORE_REPUT_9(-1.00)[162.216.242.38:from]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-0.997]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; DMARC_NA(0.00)[h8spam.org]; ASN(0.00)[asn:398019, ipnet:162.216.242.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4Z1QLT5S9Gz41gr X-Spamd-Bar: -- Sorry if this is a duplicate. This time with correct email address... February 19, 2025 10:40 PM, "Rick Macklem" wrote= : > Hi, >=20 >=20The 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 >=20He 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 >=201) 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 >=202) 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 >=203) 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 >=204) ??? >=20 >=20So, what do you think is the preferred change? IMHO Not A Bug. This is the expected behavior -- if a dependent service is not up/complet= e, then return failure. This has always held true for services dependent on name resolution. Star= t DNS early, or dependent services late. For domains/hosts you control it might be prudent to manag= e hosts(5). In any case, maybe your best option is document the appropriate man pages. I can't speak to to your software features. But maybe adding a delay, or = retry attempts may seem a good choice of Feature to you. But IMHO the reported error is pilot err= or. Anyone running NFS should already know how to remedy the situation, or be directed to the appropria= te man pages. --Chris >=20 >=20rick > 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.)