From nobody Thu Feb 20 11:47:26 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 4YzBMQ0nFhz5nmRR for ; Thu, 20 Feb 2025 11:47:30 +0000 (UTC) (envelope-from SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YzBMN4f8kz3Mty for ; Thu, 20 Feb 2025 11:47:28 +0000 (UTC) (envelope-from SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=ni0XE2Hz; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=+x+D=VL=klop.ws=ronald-lists@realworks.nl" Date: Thu, 20 Feb 2025 12:47:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1740052046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ir4HQ2mILtaZExaMAXG6QYrsBut807g1FtLdMxxs5I8=; b=ni0XE2Hz7YedMjDAGZhJ6liqOqzFdow8BrhrJn8asaSjue0ecbyhofW2kgPZhjrRxX1JIT 3xtW8Ow/Z+WFxG+RkTGnq0uVU9fcZiBRsHhJL+e25gR2ijwbkiA8lqYNhGaZhMXc4et53r AWTSCz0gdjcAXeV3mIdKhm9gWpbhLvJZn0VIYZwt+wOp2e0Bd18vxivm5Mif8aSavfnlZd SRjuRACgJQwU0iV6cz0gK/NQCPUZGQMRdMqWGyZxhb2/eVhyD9vfYMYtXJvKhFmqUpE4r6 JfIw2LZHSSKPTSiXLpeHCOmnje43OWSyEsmvOdNR50XgxgolzQRaUL8Xyw+7Tg== From: Ronald Klop To: Rick Macklem Cc: FreeBSD CURRENT , Gleb Smirnoff Message-ID: <2082771622.1171.1740052046496@localhost> In-Reply-To: References: Subject: Re: RFC: mount_nfs failure due to dns not running yet 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 Content-Type: multipart/alternative; boundary="----=_Part_1170_2115107581.1740052046373" X-Mailer: Realworks (739.8) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-4.09 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[194.109.157.24:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_FROM(0.00)[x,D=VL=klop.ws=ronald-lists]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=@realworks.nl]; DKIM_TRACE(0.00)[klop.ws:+]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from] X-Rspamd-Queue-Id: 4YzBMN4f8kz3Mty X-Spamd-Bar: ---- ------=_Part_1170_2115107581.1740052046373 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Rick Macklem Datum: woensdag, 19 februari 2025 23:40 Aan: FreeBSD CURRENT CC: Gleb Smirnoff Onderwerp: RFC: mount_nfs failure due to dns not running yet > > Hi, > > 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. > > 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. > > 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. > > 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.) > > 3) Add a new NFS mount option "retrydns=", 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". > > 4) ??? > > So, what do you think is the preferred change? > > 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.) > > > > Add the 'late' option in fstab. So DNS should be up. Assumes the NFS share is not needed during boot of course. @work we use IP addresses for NFS mounts as it is so low level in the infra that we can't assume DNS yet. And our NFS servers don't change IP address often. This has proven to be pretty robust in the past years. Regards, Ronald. ------=_Part_1170_2115107581.1740052046373 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Rick Macklem <rick.macklem@gmail.com>
Datum: woensdag, 19 februari 2025 23:40
Aan: FreeBSD CURRENT <freebsd-current@freebsd.org>
CC: Gleb Smirnoff <glebius@glebi.us>
Onderwerp: RFC: mount_nfs failure due to dns not running yet

Hi,

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.

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.

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.

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.)

3) Add a new NFS mount option "retrydns=<N>", 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".

4) ???

So, what do you think is the preferred change?

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.)
 


Add the 'late' option in fstab. So DNS should be up. Assumes the NFS share is not needed during boot of course.

@work we use IP addresses for NFS mounts as it is so low level in the infra that we can't assume DNS yet. And our NFS servers don't change IP address often. This has proven to be pretty robust in the past years.

Regards,
Ronald.
  ------=_Part_1170_2115107581.1740052046373--