unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Tarun Tej K <tarun4690@gmail.com>
To: libc-alpha@sourceware.org
Subject: getaddrinfo() fails to use latest DNS address - v2.27
Date: Tue, 7 Jan 2020 11:26:06 +0530	[thread overview]
Message-ID: <CAMvyGd868vLMjqMdogfPNcr__2LUaGXmYrdMnyHHZTVvm3By7g@mail.gmail.com> (raw)

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

                 reply	other threads:[~2020-01-07  5:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMvyGd868vLMjqMdogfPNcr__2LUaGXmYrdMnyHHZTVvm3By7g@mail.gmail.com \
    --to=tarun4690@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).