[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58520: Persistent failure to DNS-lookup hostname
From: |
Visuwesh |
Subject: |
bug#58520: Persistent failure to DNS-lookup hostname |
Date: |
Fri, 03 Nov 2023 13:27:21 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
[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
- bug#58520: Persistent failure to DNS-lookup hostname,
Visuwesh <=