Date: Mon, 24 Feb 2025 02:54:23 +0000 From: "Chris" <bsd.lists@h8spam.org> To: "Rick Macklem" <rick.macklem@gmail.com>, "FreeBSD CURRENT" <freebsd-current@freebsd.org> Cc: "Gleb Smirnoff" <glebius@glebi.us> Subject: Re: RFC: mount_nfs failure due to dns not running yet Message-ID: <4f09507d6ddba4979a418e7f30f1f94a@h8spam.org> In-Reply-To: <CAM5tNy5wA9DyBP%2BJdq1O6J=VVtXm6Rmm5rtXjJqyJRKvJ8WY=A@mail.gmail.com> References: <CAM5tNy5wA9DyBP%2BJdq1O6J=VVtXm6Rmm5rtXjJqyJRKvJ8WY=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry if this is a duplicate. This time with correct email address... February 19, 2025 10:40 PM, "Rick Macklem" <rick.macklem@gmail.com> 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<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". >=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.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4f09507d6ddba4979a418e7f30f1f94a>