From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0EB8F1F466 for ; Tue, 7 Jan 2020 05:56:23 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:from:date:message-id:subject:to :content-type; q=dns; s=default; b=VApm0pOYaCB1/R24e+cPtIvLkWm9v /9U1vPVHL/O+goQf5yf3rEZBNAoKHW2cdYqJUWyZS7blRwY7oXCCdjQ0MrJ0Czww 97+DIYkYhzey+7iWP7Ao5xCY5UmVLLtVXYH0MGSXRFLrusEbrsNBcFb5HokXA4zo fxV4yK52NtPgF4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:from:date:message-id:subject:to :content-type; s=default; bh=S5jfeCeZp3XcBi0eaqnl0YD0XBc=; b=NVo 9SexQ4Ky3rTc0Agl0F5nVzhdYB88ejK01NjwLqgvVwlyNDOEW9PlFB+VpvMp4tj5 7D8/q6fZQIoDsNRFrCuSpsVcAOa2Es40+PK1EIqVGyGCYY0JsoTJI6ZOSeniO5JT hfnfGndkml5WUcSY071Nmx9ahN7nBaWCV1LWs3fI= Received: (qmail 92068 invoked by alias); 7 Jan 2020 05:56:20 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 92057 invoked by uid 89); 7 Jan 2020 05:56:20 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f175.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2eL4oAJWaxY+mpwppLzWQ3fBetijyGJAfOB726KCO2A=; b=IKvYaXES4bxrfdihdroT3yB/2TsjfNfokArbArd3HfdeNN8/4l0xrBJXWoDT7CEQ2z fyDfHYFbQcKOHVUSaC9jDmgdQGXsYxq9JvSR5hcLmI8YX4uKWOsaL+Wwu271uG8fTZpj fcE1X/Z9TQGRNmfs7Aexn+/g6wSAsm1ENshd/K0S+JTHaMHkO0MQdyj+W2gHq0astoi4 KC7klLyieSrQsPbsOkrGqgWJ4uUcpJrATmrp7xssOKLaucXUrO3sqPx2LIbAcYizf2lI mEpgxEqYEDezltKwZ5ogXjBZx635IPRotZnq5j2/ddj4VB8I5JOq8MyZ3XZDVarR+Cn1 q3ww== MIME-Version: 1.0 From: Tarun Tej K Date: Tue, 7 Jan 2020 11:26:06 +0530 Message-ID: Subject: getaddrinfo() fails to use latest DNS address - v2.27 To: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Hi, Environment: glibc version - v2.27 platform - NXP's iMX6 cross-compiler - arm-poky-linux-gnueabi-gcc Built using the Yocto recipes As a part of long term testing of our system, I have a setup of automatic network switching between different interfaces like ethernet, wlan and ppp. During this automation, the DNS addresses in the /etc/resolv.conf keep changing because the active network interface i.e., WLAN/Ethernet/PPP keeps changing. Issue Description: The issue might be related to https://sourceware.org/bugzilla/show_bug.cgi?id=984 It is observed that once in a while, after certain duration like 5 hours or so, the getaddrinfo() fails to resolve the addresses and keep getting EAGAIN 'Temporary failure in name resolution' as return code. 'strace' output of the failing process shows that the getaddrinfo() is doing neither stat64 nor openat() of /etc/resolv.conf (to check for latest DNS change) at all when the process is in this state and may be due to this reason it is not updating the global config (resolv_conf_global) with correct DNS values. I am yet to get the steps to reproduce this issue easily. I have tried a simple application which just calls getaddrinfo() based on user input and that application always does 'stat64' of /etc/resolv.conf and openat when there is change in time or size or inode of /etc/resolv.conf But I am not sure what is causing my actual application to get into a state where it is not even doing 'stat64' of /etc/resolv.conf after some time of running 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 != NULL && replicated_configuration_matches (ctx)) { struct resolv_conf *current = __resolv_conf_get_current (); if (current == NULL) return false; /* Check if the configuration changed. */ if (current != 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 = 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 != 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 != NULL && replicated_configuration_matches (ctx)) fails? Note: One thing about /etc/resolv.conf if it helps. Depending the type of active network interface the application changes file type of /etc/resolv.conf is sometimes regular file or symlink to /var/run/resolv.conf. Could the /etc/resolv.conf being a symlink cause any problem like this. Thanks Tarun