bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier]

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