Date: Sat, 22 Feb 2025 06:49:55 -0800 From: Rick Macklem <rick.macklem@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: Toomas Soome <tsoome@me.com>, FreeBSD CURRENT <freebsd-current@freebsd.org>, Steve Rikli <sr@genyosha.net> Subject: Re: RFC: mount_nfs failure due to dns not running yet Message-ID: <CAM5tNy7BFQNDRMLKMAvwdJroZehNzqaRTnrHXEEhgYbJwNYfRQ@mail.gmail.com> In-Reply-To: <Z7joDRfmwz467kDF@cell.glebi.us> References: <CAM5tNy5wA9DyBP%2BJdq1O6J=VVtXm6Rmm5rtXjJqyJRKvJ8WY=A@mail.gmail.com> <Z7fIlo1Dt6AfO%2BZx@dragon.home.genyosha.net> <CAM5tNy55atdBE2iNhhEWBPcytSe=ikXW00kN1fRqJr8HXQpuYg@mail.gmail.com> <862576B0-EFBF-4CC9-B99A-723125D60983@me.com> <CAM5tNy4A7x5BAW5aoNQiNdqTSqPPLc7xapcD7GipF_XAMbKOCQ@mail.gmail.com> <Z7joDRfmwz467kDF@cell.glebi.us>
index | next in thread | previous in thread | raw e-mail
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 Smirnoffhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy7BFQNDRMLKMAvwdJroZehNzqaRTnrHXEEhgYbJwNYfRQ>