bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier]

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