From nobody Sat Feb 22 14:49:55 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 4Z0VKN6D7tz5nmfW for ; Sat, 22 Feb 2025 14:50:16 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z0VKN0SBYz3L8H; Sat, 22 Feb 2025 14:50:16 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5ded1395213so5164488a12.2; Sat, 22 Feb 2025 06:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740235814; x=1740840614; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ja7P5wLM1wHtZKncQPPuVXEHtL+OaMNbLVnqisdsKdw=; b=Y0Z2u1enEqTe3w3A++Tt4Ill0fpV0ozwOi6I1sEPGzS32WqCDQADx2pvDLlzGxDFoD JWBu0Rk7+d2xVaTqfK/xlLAAt9xrXL2QxeYVg+0TLUP+CZcDJld08sf8ZpwsT18wD52t 3XkiTmXdvef6U5B1EMW63Uq963m0YsBefwDQxYBTp6jlAw+xL1cMFcpC3JxNAmdBtDvN Ks6Ca1xhAud8inffhffjdMhIAlizBWG27nn9myRNnT0Mcf3C6ZO3lCTOoa7l4loAZUZs gFViiRs+0AicY/ftfWaArShFf6aPGHgddqFZgfXmACqhHgPRIO6hUEy8LIn5pMNk9Xu4 LOVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740235814; x=1740840614; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ja7P5wLM1wHtZKncQPPuVXEHtL+OaMNbLVnqisdsKdw=; b=M/kZuNgELDlatQCEaCm5HJ314oKESa9qur+qDCLAXPdP4j8GiOp19TjICjwLG6cnbw 4bvbXv9rn4hXNZ1G3swTrkzpyeAvJ+NpoPTe7DgLyY+1i9dMQg0pc9bPpccsjvqJrtsx 0TqjYA3ClBg9KzhIiLTj79KqOo6BaSuxplXvuJHIKv44zN/6rua3Dy1J6uStu6BtAxa0 G4Na6aVLD1BAppXQDDu2GFrs5x1izWOvRaigCWEWeASm6/PtwGLP6gkKarTAvvaM7OB3 8MdaVLucbDz9FCBKHwmR4bBYjoZOalmNDuIuYRFiywJOC6iEceDlub/BMn4O81235ta1 ZRew== X-Forwarded-Encrypted: i=1; AJvYcCVGGrwUMoX+KHwu8ljVAKknnIP6Zb4bwlqDbBOh7VytXmigaagqDUqeiJ/U+AZnvZkIaSAwfOuqKob7tBrYvj8=@freebsd.org X-Gm-Message-State: AOJu0YyamnFJvzec3dQXjrQQWc65yTMnKEOfKe8k65/bin5gRVbCK/9C LCVg/MOuGvvu0YVFgqMs4wW2cg03OlEdLHoNQ8psGC6yq33IS4fGIr/zU841nJQ12Wn8WwY4BMK FUC7hmVs8IOW+kn7B4CRMWAAEqxV5 X-Gm-Gg: ASbGncsTfdHroe3L2rclYXXA6MHpM12O/pSQCvsYSAZMp814cjqWS/WrGZfp0WfUheH 4MvrJHc/hJZ4Aqb3TPEqupmF7l2ZkIbaj1cuIiX+I/FOM7nrlm/HmEQWCmaRFA/EFipAOYaPVLY hL1MKwLbtqZi3fm8eISU2nYD44omsbNK9Xm7gTY93z X-Google-Smtp-Source: AGHT+IHb9Y+fhVJdlPT/4SJuhHJHJIsY2cqrY7IDjScA51cyORNC6UDBAUsjwGSGPujh1ZHyGu81+J3b7W0JgRkXK5w= X-Received: by 2002:a05:6402:350f:b0:5dc:c9ce:b022 with SMTP id 4fb4d7f45d1cf-5e0b70e4ddemr6559339a12.9.1740235813607; Sat, 22 Feb 2025 06:50:13 -0800 (PST) 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 References: <862576B0-EFBF-4CC9-B99A-723125D60983@me.com> In-Reply-To: From: Rick Macklem Date: Sat, 22 Feb 2025 06:49:55 -0800 X-Gm-Features: AWEUYZm7Qf9iSQxsA7Drp4oBQ9nq0dDGrrPDC-ncHtpZEfYnF0H8EfO3dIP1Ojk Message-ID: Subject: Re: RFC: mount_nfs failure due to dns not running yet To: Gleb Smirnoff Cc: Toomas Soome , FreeBSD CURRENT , Steve Rikli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Z0VKN0SBYz3L8H X-Spamd-Bar: ---- On Fri, Feb 21, 2025 at 12:54=E2=80=AFPM Gleb Smirnoff 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 clea= rly > R> differentiate between them. I think Gleb's case returns EAI_FAIL, whic= h is also > R> returned for other failures. I think EAI_NONAME is returned for the ca= se 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 E= AI_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 doi= ng for > years. E.g, they need to run a new command to achieve same result as the= y 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 hang= s 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/re= view, 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 al= ready > very uncommon for command line mount_nfs. Second, again nothing changes = for > them if everything is all right with their network. Only if their networ= k/DNS > is off, they would see mount_nfs(8) going into background instead of fail= ing. 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. We= ll, > very far fetched POLA violation. > > -- > Gleb Smirnoff