From nobody Thu Feb 20 00:29:42 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 4YyvKP6RGKz5nvw5 for ; Thu, 20 Feb 2025 00:29:45 +0000 (UTC) (envelope-from dan@3geeks.org) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 4YyvKN6wKZz3jlj for ; Thu, 20 Feb 2025 00:29:44 +0000 (UTC) (envelope-from dan@3geeks.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=3geeks.org header.s=google header.b=j4hx5QbU; dmarc=pass (policy=none) header.from=3geeks.org; spf=pass (mx1.freebsd.org: domain of dan@3geeks.org designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=dan@3geeks.org Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6fba8e84d3cso3093647b3.0 for ; Wed, 19 Feb 2025 16:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=3geeks.org; s=google; t=1740011384; x=1740616184; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=4wSE2k8pbPQAMnrwKDpSLN2yBP0I6vHfLpOFo8bPEh4=; b=j4hx5QbUXAsBuE70OBTqTQ3MwJq/DSGnr2SIYkM/RYDjqIk8nqr9dtif8AnM+9+u8/ LbeMrI8JkuK/DrFIpQdaOa847fb1m39f7zb/ChY32G4UUp4jiE93JJInhK/IUwQwCzSF A8HwlcX9BwTWP/CAsu1PHTGXFuKSOJy7UscfA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740011384; x=1740616184; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4wSE2k8pbPQAMnrwKDpSLN2yBP0I6vHfLpOFo8bPEh4=; b=NMAFZUSaE6IVc5d21kO0rpAIZG1TtZsqxSAtczDs1hUnYHQDsSD/LnNg7peh1QabVh cn+pHGQgrANWfWseSVIjUJcOolK0M1pPSkz1A+j4THmZv2/8f6b7JYVNatNYi4thLoDx /yBjpAgqNVAqDUiY59wR5hR8Wq1XE3bNo9PU0OLvOVUnW2v4icRKP1K20QjpobKtqDKE EOuioP2lcKO+kt4h7Nfiy4ZW/BYz0UeItPk/AHc8yjkW/V/BkBIK3d90jCLVTJ/IIdBe BZC7cYs0+k1t8EmFCbhn6aPcDxwddyB1WPO8cRauWcjinQ+R2b0HX4VRyxsPBA3twyqw Iiig== X-Gm-Message-State: AOJu0YzE7FtgGPWGRNthsosbQsUCmgQFdfPf28Y6j6yQksYcR0EHosgw V+G8qYwPJ/Uunnd1I+FTNOI6RI8tGi7jyaJp0Kz9EoUP9ZsduG8C4hpADq0CZpreA55mjVjJS9M O X-Gm-Gg: ASbGnct2kbFx6Sk1v7vl3pYc565rolPjwz2a396scHSWbFafXJZ7xtxMNoS9KknvA/Q 2hXGnQdPKSCedOqz9Rp6EpbqRKW/txsy4QhA4OMlNrH1uk4pVeCYYLQDu63zCvFqELpRGIwgidB BpIwxx8pIyVzwmsufcl2WHAiAtYUDoGOOi+FcpVevSYe2RqCtsCCkSNnuV8Owws4Q3LChcxxcJj 5laF/vZTAMVtTKr7JesUy0dLZip/5sHni2uY5qOE2z+K5QM8Qqy25r0eMfHMoC2kTxXJOEZy6EZ ztBofUUqwBk4tUDd5rqIKA626BjNku3NlDHYnYyugdqrGfWl+RMt3LOvg86O X-Google-Smtp-Source: AGHT+IHZWgkfWYwiSyO0YVUzA/ZdlS4gM8lJTF75kkdV7qisMYcQ2ukf12jUtu6mxT8ibVd2tJ5nQQ== X-Received: by 2002:a05:690c:25c5:b0:6ef:4a1f:36d6 with SMTP id 00721157ae682-6fb5831d609mr181653587b3.23.1740011383750; Wed, 19 Feb 2025 16:29:43 -0800 (PST) Received: from [192.168.21.197] (69-237-9-85.lightspeed.dybhfl.sbcglobal.net. [69.237.9.85]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6fbb72f48f3sm1923717b3.6.2025.02.19.16.29.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2025 16:29:43 -0800 (PST) Message-ID: <56736af6-e72a-4d91-a56d-cde0f5e32252@3geeks.org> Date: Wed, 19 Feb 2025 19:29:42 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: RFC: mount_nfs failure due to dns not running yet To: freebsd-current@freebsd.org References: Content-Language: en-US From: Daniel Mayfield In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.66 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.66)[-0.662]; DMARC_POLICY_ALLOW(-0.50)[3geeks.org,none]; R_DKIM_ALLOW(-0.20)[3geeks.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[3geeks.org:+]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[dan]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1135:from] X-Rspamd-Queue-Id: 4YyvKN6wKZz3jlj X-Spamd-Bar: --- On 2/19/25 5:40 PM, Rick Macklem wrote: > Hi, > > The 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. > > He 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. > > 1) 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. > > 2) 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.) > > 3) Add a new NFS mount option "retrydns=", 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". > > 4) ??? Split the difference?  -1 for "try forever", default to 3, configurable up to insanity?  Also, rather than just DNS, make this in the case of just about any failure except actual administrative failure (mountd refusing the mount, for example). If this gets added, there should either be an exponential backoff with a configurable max (default to 30s), or a configurable static delay (default to 3s? 10s?).   The mount_nfs process should log loudly every time the delay gets triggered. Honestly, this would be handy in any number of crazy situations where you have a need to wait for something else to start.  I've been bitten by the "just fail the mount" behavior before, but I worked around it instead of thinking of changing the behavior. Daniel