bug#58520: Persistent failure to DNS-lookup hostname

[Visuwesh]

[Tuesday September 05, 2023] Stefan Monnier wrote:

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

FWIW, I experience this sometimes when I change from an Ethernet
connection to a WiFi connection (I cannot remember if the inverse is
true too).  This change to another connection once I wake my laptop from
hibernation.  During this change, /etc/resolv.conf definitely changes
because I use resolvconf to set connection-specific and
interface-specific DNS nameserver setting.  [ I need to set the DNS
server manually for the Ethernet connection but I can use dhcp for the
Wifi one.  ]

Emacs throws me `443 Temporary failure in name resolution' even though I
can open the same address in Firefox, or a fresh new Emacs instance just
fine.  In fact, I couldn't use gnus-read-ephemeral-emacs-bug-group from
the failing Emacs instance but I can in this fresh one I opened just to
send this mail.

The other super weird part is that eww _can_ open debbugs.gnu.org just
fine, but if I use Gnus to fetch the bug report it doesn't...
More generally, eww seems to be able to open these webpages just fine
but if I do a HTTP request to same address using url.el it fails with
the aforementioned 443 error.  I can sometimes stop this error once and
for all by visiting the failing address in eww but clearly this time it
hasn't helped (since Gnus still fails to make a connection to
debbugs.gnu.org after visiting debbugs.gnu.org in eww).

I am not sure how long this failing Emacs instance will fail but if it
helps, I can try to do some debugging on my end as well.  I tried to use
tcpdump but the manpage seems to suggest that there is no way to filter
network requests made by a particular process, and I see too many junk
requests to isolate the traffic that matters.

>         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