From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126897 invoked by alias); 7 Jan 2020 08:52:43 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 126886 invoked by uid 89); 7 Jan 2020 08:52:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_40,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=resource, tej, H*Ad:U*libc-help, getaddrinfo X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Jan 2020 08:52:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578387161; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z2eu8Vf4sDGuI/kJ6iI47J45N6Q7dWfeUJfss0itHwA=; b=iKWl38mNodbJTn0QLbk+dRht7T5pmtpvQgiP9RaYCq4uVZCxm+RFJ7bZrz7NwU/NIN513C sUeZuSklUH+XJv/Y5QH2PY0PMANvyUn5XFhSdqlkOZpJYVDTVON5NuFvbYygGNhKvEyuHC 2VTyoWi7SEglX/v8VoIFB/i4FJXH3pM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-143-JLI2DjWYPy2lDbFo35OX1A-1; Tue, 07 Jan 2020 03:52:38 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 00E89107ACC5; Tue, 7 Jan 2020 08:52:37 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-117-48.ams2.redhat.com [10.36.117.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 471CC84FE2; Tue, 7 Jan 2020 08:52:36 +0000 (UTC) From: Florian Weimer To: Tarun Tej K Cc: libc-help@sourceware.org Subject: Re: getaddrinfo() fails to use latest DNS address - v2.27 References: Date: Tue, 07 Jan 2020 08:52:00 -0000 In-Reply-To: (Tarun Tej K.'s message of "Tue, 7 Jan 2020 11:31:31 +0530") Message-ID: <87lfqjwsvh.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00006.txt.bz2 * Tarun Tej K.: > I have gone through glibc code and have a query regarding below part > from the function maybe_init() in file resolv/resolv_context.c > > if (ctx->conf !=3D NULL && replicated_configuration_matches (ctx)) > { > struct resolv_conf *current =3D __resolv_conf_get_current (); > if (current =3D=3D NULL) > return false; > /* Check if the configuration changed. */ > if (current !=3D ctx->conf) > { > /* This call will detach the extended resolver state. */ > if (resp->nscount > 0) > __res_iclose (resp, true); > /* Reattach the current configuration. */ > if (__resolv_conf_attach (ctx->resp, current)) > { > __resolv_conf_put (ctx->conf); > /* ctx takes ownership, so we do not release current. = */ > ctx->conf =3D current; > } > } > else > /* No change. Drop the reference count for current. */ > __resolv_conf_put (current); > } > return true; > > Here the return value will be 'true' even when the condition if > (ctx->conf !=3D NULL && replicated_configuration_matches (ctx)) fails. I > think that this is one case where __resolv_conf_get_current() or > __resolv_conf_load() would not be called and so 'stat64' or openat() > would not be done on /etc/resolv.conf. Why is the function maybe_init > returning 'true' when the condition (ctx->conf !=3D NULL && > replicated_configuration_matches (ctx)) fails? The expectation here is that __resolv_conf_load performed the stat64 call and reloaded the configuration if necessary. maybe_init returns false only in case of resource exhaustion (e.g., memory allocation failure). Doe this answer your question? I'm afraid the bug must be elsewhere. We use stat64 in __resolv_conf_get_current, so it should not matter whether /etc/resolv.conf is a symbolic link or not. I believe the function deals correctly with missing files or symbolic links that cannot be resolved. It produces an invalid, all-zero stat result and caches that. If the file becomes available again, the cached contents no longer matches, and a reload is triggered. How do you replace /etc/resolv.conf? If the file is overwritten in-place and the file system does not have nanosecond resolution for its timestamps, then glibc might read an empty (or partial) /etc/resolv.conf file, but might not realize that the file changed again later because the subsequent writes do modify the file timestamps (due to the timestamp resolution). The fix is to write the new version of /etc/resolv.conf to a temporary file (in the same directory) and rename it into place, atomically. Thanks, Florian