From nobody Fri Feb 21 20:54:37 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 4Z02SJ4HKmz5pKgX for ; Fri, 21 Feb 2025 20:54:40 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z02SJ3Gwfz4PSN; Fri, 21 Feb 2025 20:54:40 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740171280; 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=M5RUB1ywQdmPt1L/jRDWwS1NnuvFzm6EDkx/1iO0Axg=; b=wfM/MCLT5GrPwfml0LgynWLUgsgc+bPHlwPVBINoxHGdmNP/M0d4IecDnURfGHUnVAbNbI 53iJetjOgiIxfnhelwnD0fbv4TCgQHskqYpWbGas9+fdCZvJUQrPDu3QEbI86XG8usJU45 X9ehdrlO8sx/nAgxJBFr3aRWpIedpEQkFQ8vGhOQyo1cgdalORWjgU5fDTDwnGQHVZtoJU VgLKgtHZcnq6Syq8T6AaNZi3pECekNIAO8BWOyDmiLJaDIqHf58SkNMqG6HL8koE4xOe1H VVTWlM122K164twEb5w7OnapUQkVOgSHpmsYWe8DEbhcW0NnEM+5xN9ce2r8NA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1740171280; a=rsa-sha256; cv=none; b=KDVO4iAvytTZF4aVzJQKyJBlzz8WnRTCSeAkCo/ZdM2VmfEAYejZKZH6kY2z7CpgdU9+pH kprdoc2Y8NcXSFtreLhYrGgfJQch6F1JKOLZ5uSMYwoFt2h0h1zlxxTGyq4Ruh4GqKWrb4 Jm1Uq8a4u4NttGwRB+bAbft+vC9ujRAWlpHK4IIsoFfypflmP+51PIb2GKdQ+GM4bgpNPh WC6aXxSefCZCd95rhl9SIoE4+exJ2Vd7ES+OJ3o/APr6kzsd/fNH5pHXs4d3vXa12SqEwV GkREB93vw1kDr5j2cfWcdwUAc0hnDZm3Qxazw5Io8FmsAWkOf5Kd2+cN0+pt4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1740171280; 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=M5RUB1ywQdmPt1L/jRDWwS1NnuvFzm6EDkx/1iO0Axg=; b=FQyCxRFqbLBhYg1qMtc7hYaAJvabgy2t+BXaiB5r1loSvBtOFF6T/bCDIFz58mi7i8hL9R vSgMsufpbbCXxmG63jPdLAlpNxV12huZrVmgqkPPj0JeCGiKOn31YRPoXGf1aW6pSos4hJ AJNjecUvhyZfvdLw2skqFv/k9ZS9TonisFJGLx90UZyjEWVwvpa1rueyNNC6X4o75+DGzj xF+S6n8/f7OHRvwX1gUnt8MSbMnVPyDvG2JrAJKZxwGwZH8H/72Vw8VkkTTULX3poTQtIR x+iN/8qnG6QB6l5PbBJ60J3vKoUrSu+gzHz6x/8QVQuRFYpYZZFtJILDA2qzDg== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Z02SH4pc4zLrS; Fri, 21 Feb 2025 20:54:39 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 21 Feb 2025 12:54:37 -0800 From: Gleb Smirnoff To: Rick Macklem Cc: Toomas Soome , FreeBSD CURRENT , Steve Rikli Subject: Re: RFC: mount_nfs failure due to dns not running yet Message-ID: References: <862576B0-EFBF-4CC9-B99A-723125D60983@me.com> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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? * 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