Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fd91b129-b383-9b1d-0978-032a7ff92dbb@redhat.com>
Date:   Mon, 17 Jul 2023 17:48:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: [PATCH 0/2] Mitigate startup race between DNS resolution and
 idmapd
Content-Language: en-US
To:     Aram Akhavan <github@aram.nubmail.ca>, linux-nfs@vger.kernel.org
References: <20230613034625.498132-1-github@aram.nubmail.ca>
From:   Steve Dickson <steved@redhat.com>
In-Reply-To: <20230613034625.498132-1-github@aram.nubmail.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 6/12/23 11:46 PM, Aram Akhavan wrote:
> idmapd needs DNS resolution on startup if a domain isn't specified by
> config file. This isn't trivial since even with systemd's
> network-online.target, DNS resolution isn't guaranteed. On Debian,
> for example (in part due to some lingering bugs), adding the
> target, and even enabling the not-well-documented
> ifupdown-wait-online.service is not enough. These two patches aim to
> improve the startup behavior in common setup scenarios.
> 
> Aram Akhavan (2):
>    nfs-idmapd.service: add network-online.target to Wants= and After=
>    libnfsidmap: try to get the domain directly from hostname if the DNS
>      lookup fails and always show the log message if the domain can't be
>      determined
> 
>   support/nfsidmap/libnfsidmap.c | 15 ++++++++++-----
>   systemd/nfs-idmapd.service     |  3 ++-
>   2 files changed, 12 insertions(+), 6 deletions(-)
> 
Both committed... (Tag nfs-utils-2-6-4-rc3)

steved