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: Fri, 14 Oct 2022 12:20:52 -0400	[thread overview]
Message-ID: <jwvwn92idgb.fsf@iro.umontreal.ca> (raw)

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






             reply	other threads:[~2022-10-14 16:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14 16:20 Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-10-14 16:55 ` bug#58520: Persistent failure to DNS-lookup hostname 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
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=jwvwn92idgb.fsf@iro.umontreal.ca \
    --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).