From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67181 invoked by alias); 7 Jan 2020 12:27:51 -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 67164 invoked by uid 89); 7 Jan 2020 12:27:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=forever, H*Ad:U*libc-help, corruption, H*i:sk:CAMvyGd X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Jan 2020 12:27:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578400068; 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=U+VUD3S+RoxJDXsJ+NWsRgb2yQB4S99xPHnt8oP90rI=; b=YZ0ahQ0rKNKW6aXwNOkthGSGIN/yPuSbF4IJ0kRAAeUTL/dqyLUEwXX0RskZ1Xz0ZxYkPo Hyzgyc84ZVsVa3BWA2dEUJG0FB/77itbkWesFAuwT4AQLy2H5mNyiOia6EDIg2CFTZNLPF QR7/ARfssyKiC2miQ2QaX29cMY/g4AM= 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-300-wHtcWMvjOXu6rXSpnSvfcw-1; Tue, 07 Jan 2020 07:27:44 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AC74F801E7E; Tue, 7 Jan 2020 12:27:43 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-227.str.redhat.com [10.33.192.227]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 160BF60BE2; Tue, 7 Jan 2020 12:27:42 +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: <87lfqjwsvh.fsf@oldenburg2.str.redhat.com> Date: Tue, 07 Jan 2020 12:27:00 -0000 In-Reply-To: (Tarun Tej K.'s message of "Tue, 7 Jan 2020 15:15:31 +0530") Message-ID: <87y2ujtps2.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/msg00008.txt.bz2 * Tarun Tej K.: > As per the strace, when problem occurs even stat64 call is not taking > place. (That means __resolv_conf_get_current is not being called?) Yes. > In any case, shouldn't stat64() happen everytime the getaddrinfo() is > called? Indeed. > Can you please suggest any way to investigate why even stat64 was not > happening and getaddrinfo is returning with EAGAIN forever until the > process is restarted? It could mean that reloading is disabled. There are a few possible causes: * The noreload option is specified in /etc/resolv.conf. * The application sets RES_NORELOAD in res.options directly. * The application updates other data in _res, so that it no longer matches the previously read configuration. The last part could also happen due to completely different bugs, e.g. after heap corruption. Regarding bugs, I'm not aware of any. In general, reloading of the configuration is inhibited for a thread if it has an attached context. Maybe there is a bug in this area. Do you have a coredump? It should be visible in the current variable in resolv/resolv_context.c. > Also could you suggest any other tool other than strace to see the > call trace of libc runtime? Systemtap might be an option. Thanks, Florian