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