Re: RFC: mount_nfs failure due to dns not running yet

From: Rick Macklem <rick.macklem_at_gmail.com>
Date: Sat, 22 Feb 2025 14:49:55 UTC
On Fri, Feb 21, 2025 at 12:54 PM Gleb Smirnoff <glebius@freebsd.org> wrote:
>
> On Fri, Feb 21, 2025 at 05:06:16AM -0800, Rick Macklem wrote:
> R> Agreed. Unfortunatey, the return values for getaddrinfo(3) do not clearly
> R> differentiate between them. I think Gleb's case returns EAI_FAIL, which is also
> R> returned for other failures. I think EAI_NONAME is returned for the case where
> R> the resolver (dns, /etc/hosts or ???) does determine that the name is bogus.
> R>
> R> I suppose the code could do retries for all return values other than EAI_NONAME,
> R> but to me that would still be a POLA violation, since the current
> R> behaviour has been
> R> in place for decades (as others have noted).  Also, some of the
> R> feedback here has
> R> been "It is not broken, don't fix it", if I interpreted it correctly.
> R> A new option avoids
> R> changing the default behaviour.
>
> I would argue that there is no POLA breakage here.  POLA violation means that
> people would need to learn something new, different to what they were doing for
> years.  E.g, they need to run a new command to achieve same result as they did
> before, or run they same command but observe a different result.  The fix does
> changes behavior of mount_nfs, but does it change anything for a user, an
> operator or a sysadmin?
What about the case where without any patch, the mount fails and the system
continues to boot normally otherwise, whereas with a patch, the system hangs
while booting, trying to do the mount?
(Although you noted different behaviour for "late", I believe an NFS
mount without
"bg" should block further startup until the mount succeeds. An NFS mounted /usr,
for example.)

I have put a patch up on phabricator as D49104 which I hope you can test/review,
ignoring the fact that you do not think fixing it by default is a POLA
violation.

rick

>
> * Those who use IP addresses in /etc/fstab - nothing changes for them.
> * Those who use name from /etc/hosts in /etc/fstab - nothing changess for them.
> * Those who use DNS names in /etc/fstab (but didn't run into issues until now)
>   - nothing changes for them.  And a potential issue is fixed for them.
>
> What about somebody, who run mount_nfs(8) from command line?  First, they would
> need to run with 'bg' option, to see any behavior difference, which is already
> very uncommon for command line mount_nfs.  Second, again nothing changes for
> them if everything is all right with their network.  Only if their network/DNS
> is off, they would see mount_nfs(8) going into background instead of failing. I
> do claim that this is a positive change, someone would argue that people may
> use mount_nfs(8) as a probe for working DNS and that would be broken.  Well,
> very far fetched POLA violation.
>
> --
> Gleb Smirnoff