unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: 58520@debbugs.gnu.org
Cc: Paul Eggert <eggert@cs.ucla.edu>
Subject: bug#58520: Persistent failure to DNS-lookup hostname
Date: Tue, 05 Sep 2023 13:06:11 -0400	[thread overview]
Message-ID: <jwv1qfck120.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <jwvwn92idgb.fsf@iro.umontreal.ca> (Stefan Monnier's message of "Fri, 14 Oct 2022 12:20:52 -0400")

FWIW, I've seen this bug on a somewhat regular basis.  I have not been
able to reproduce it: it seems to show up only after Emacs has been in
use for several days.

I did confirm that calling `M-: (res-init) RET` does work around the
problem in the sense that the Emacs session can then successfully
perform DNS lookups again.
[ `res-init` is a little DEFUN I added which just calls `res_init`.  ]

So, as far as I can tell, the problem is that glibc or Emacs somehow get
into a state where the automatic decision to refresh the info about the
address of the DNS server doesn't work any more.


        Stefan


Stefan Monnier [2022-10-14 12:20:52] wrote:

> Package: Emacs
>
>
> [ I see that my original email was sent to emacs-devel, but I think
>   bug-gnu-emacs is a better place for that.  ]
>
> My Gnus session (a separate Emacs session I use specifically to run
> Gnus) occasionally gets into a state where it insists that my mail
> server's DNS name isn't found.  All(?) other processes on the machine
> keep happily resolving hostname, so the problem is specific to
> this process.
>
> The problem just reappeared today and thanks to the help I got last time
> I managed to diagnose it a bit better:
>
> - Lars asked if it only affect IMAP: nope, it affects more than just
>   IMAP.  Simple tests suggest it affects all DNS lookups performed by
>   that Emacs process.
> - Madhu suggested the problem was related to commit 93bf7d52841c60ff and
>   might be linked to a lack of call to `res_init`.  For some stupid
>   reason I wasn't able to add an ELisp primitive that lets me call
>   `res_init` manually to verify this hypothesis, but I now figured what
>   was my mistake, so I should be able to try `M-: (res-init) RET` next time
>   to confirm that it works around the problem.
> - Robert's suggestion to use `tcpdump` showed that the reason this Emacs
>   process gets DNS lookup failures is simply that it queries the DNS
>   server at 192.168.1.1 which is the server I was using yesterday (and
>   to which I currently don't have access) rather than the one I'm using
>   now.  IOW, it strongly suggests that the problem would be solved by
>   calling `res_init`.
>
> [Glibc bug 984](https://sourceware.org/bugzilla/show_bug.cgi?id=984)
> seems relevant.  According to this, calling `res_init` should not be
> necessary any more.  Indeed, if I start Emacs, use
> `make-network-process`, then change `/etc/resolv.conf`, then call
> `make-network-process` again, tcpdump shows clearly that the Emacs
> session has noticed the change in `/etc/resolv.conf`.  I tried this same
> test from a fresh new Gnus session, and that also works fine.
>
> So it's still a mystery why my Gnus session sometimes gets into a state
> where it apparently stops paying attention to changes in
> `/etc/resolv.conf`.  The above bug 984 mentions that glibc's "auto
> reload" of `/etc/resolv.conf` is prevented in case the application has
> modified `_res` manually, but I can't see any place where we do that.
> Could it be that some of the libraries we link with can sometimes
> manually modify `_res`?
>
>
>         Stefan






  parent reply	other threads:[~2023-09-05 17:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14 16:20 bug#58520: Persistent failure to DNS-lookup hostname Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 16:55 ` Paul Eggert
2022-10-14 17:17   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-05 17:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-11-03  7:57   ` Visuwesh
2023-11-03 16:38     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-03 18:46       ` Visuwesh
2023-11-03 21:54         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-04  2:31           ` Visuwesh
2023-12-11 11:54             ` Visuwesh
2023-12-17 23:27               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-18 17:30                 ` Eli Zaretskii
2023-12-18 17:41                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-18 17:55                     ` Eli Zaretskii
2023-12-18 18:26                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

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/emacs/

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

  git send-email \
    --in-reply-to=jwv1qfck120.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=58520@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=monnier@iro.umontreal.ca \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).