bug#58520: Persistent failure to DNS-lookup hostname

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

[Paul Eggert]

Also see this informative thread by the Go folks, who see a similar bug 
and have some good worries about thread safety and who are still seeing 
problems as of August:

https://github.com/golang/go/issues/21083

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Paul Eggert [2022-10-14 09:55:12] wrote:
> Also see this informative thread by the Go folks, who see a similar bug and
>  have some good worries about thread safety and who are still seeing
>  problems as of August:
>
> https://github.com/golang/go/issues/21083

The beginning of the thread is all about an old version of glibc
(i.e. before glibc started auto-reloading the `/etc/resolv.conf` file).

The last comment does seem like it might be related (it's for a more
recent globc), admittedly, but that one is rather short on details.


        Stefan

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Sounds like the exact same problem, indeed.
If you ever come up with some further hints about what it needs to
reproduce it (or even better: an actual recipe), I'd be happy to hear them.

Currently it seems that hibernate/suspend might be related, tho
I suspect it's a red herring.

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

Hmm... any chance that you're using some package which makes `eww` use
some external tool instead of `url.el`?

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

AFAICT once it happens it doesn't fix itself: the DNS server used by
your Emacs process is "stuck" and doesn't pay attention to
/etc/resolv.conf, so it "gets fixed" if you happen to be connected on
a network where the DNS server that Emacs tries to contact is available.

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

I used a filter which only kept packets sent to a DNS port (port 53) and
that was sufficient to see requests to the "wrong" DNS server (e.g. the
one you use when your machine is connected via Ethernet, even though
the machine is currently connected via wifi) and to confirm that those
requests are correlated with the operation I perform in Emacs.


        Stefan

bug#58520: Persistent failure to DNS-lookup hostname

[Visuwesh]

[வெள்ளி நவம்பர் 03, 2023] Stefan Monnier wrote:

>> 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.  ]
>
> Sounds like the exact same problem, indeed.
> If you ever come up with some further hints about what it needs to
> reproduce it (or even better: an actual recipe), I'd be happy to hear them.

Unfortunately, I only experience this intermittently.  This is the first
time I see this issue in months (but could also be because I haven't
been bringing my laptop as often to the WiFi-only building).

> Currently it seems that hibernate/suspend might be related, tho
> I suspect it's a red herring.

You may be right about that but I cannot exactly prove it because
walking while carrying my laptop with its lid open for 2 km is not going
to be fun.  :-)
I don't want to turn off suspend-on-lid-close and potentially overheat
my laptop either.

>> 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...
>
> Hmm... any chance that you're using some package which makes `eww` use
> some external tool instead of `url.el`?

No, I don't use any nor do I know of such a package.  Actually, an even
stranger thing happened with eww that I neglected to mention: some
requests to search.brave.com clearly failed with the lookup failure but
eww made enough requests to render the webpage from Brave search just
fine.  This is what I see in the *Messages* buffer

     1 Contacting host: www.doi2bib.org:443
     2 Error: (error www.doi2bib.org/443 Temporary failure in name resolution)
     3 Contacting host: search.brave.com:443
     4 search.brave.com/0 Temporary failure in name resolution
     5 cdn.search.brave.com/0 Temporary failure in name resolution
     6 cdn.search.brave.com/0 Temporary failure in name resolution
     7 Contacting host: www.doi2bib.org:443
     8 Error: (error www.doi2bib.org/443 Temporary failure in name resolution)
     9 Contacting host: www.doi2bib.org:443
    10 open-network-stream: www.doi2bib.org/443 Temporary failure in name resolution
    11 Contacting host: search.brave.com:443
    12 cdn.search.brave.com/0 Temporary failure in name resolution
    13 Contacting host: www.doi2bib.org:443
    14 open-network-stream: www.doi2bib.org/443 Temporary failure in name resolution
    15 Contacting host: doi2bib.org:80

Line nos. 1 and 2 are from url.el requests.  3--6 and 11--12 is from
connection to search.brave.com from eww for an internet search.
I cannot say with confidence but 15 should be when I opened doi2bib.org
in eww once it became obvious that url.el will keep on failing...

>> 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.
>
> AFAICT once it happens it doesn't fix itself: the DNS server used by
> your Emacs process is "stuck" and doesn't pay attention to
> /etc/resolv.conf, so it "gets fixed" if you happen to be connected on
> a network where the DNS server that Emacs tries to contact is available.

Your analysis seems to be correct.  Now that I'm back on the Ethernet
connection, Emacs can happily make all the network requests its heart
desires.  

But I seem to recall a similar failure back when you initially spoke of
this issue (even before opening this bug report) and I think I solved it
by opening the failing webpage in eww, which is why I tried this again
today for doi2bib.org.  It seemed to have worked once i.e., eww opened
the website but failed again when I tried a second time.
So for all I know, it could have been sheer luck.

>> 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.
>
> I used a filter which only kept packets sent to a DNS port (port 53) and
> that was sufficient to see requests to the "wrong" DNS server (e.g. the
> one you use when your machine is connected via Ethernet, even though
> the machine is currently connected via wifi) and to confirm that those
> requests are correlated with the operation I perform in Emacs.

That sounds a bit too involved for me currently.  If I get more time
(this might not happen until January) and if the bug shows its face
itself again, I will try to look into this in greater detail to help
squash this bug.

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Unfortunately, I only experience this intermittently.

Same here :-(

> You may be right about that but I cannot exactly prove it because
> walking while carrying my laptop with its lid open for 2 km is not going
> to be fun.  :-)

Same here :-)

Tho I don't want to leave it ON during the night or those days where
I don't use it either.

>      3 Contacting host: search.brave.com:443
>      4 search.brave.com/0 Temporary failure in name resolution
>      5 cdn.search.brave.com/0 Temporary failure in name resolution
>      6 cdn.search.brave.com/0 Temporary failure in name resolution
[...]
>     11 Contacting host: search.brave.com:443
>     12 cdn.search.brave.com/0 Temporary failure in name resolution

> Line nos. 1 and 2 are from url.el requests.  3--6 and 11--12 is from
> connection to search.brave.com from eww for an internet search.

Seems like the accesses failed just as well, so my guess is that the
only thing different with EWW is that it falls back on a cache or
something like that.

> That sounds a bit too involved for me currently.

I don't think it's necessary either.  The circumstantial evidence is
strong enough to conclude that you're seeing the same symptoms as I and
that it comes from the same source.


        Stefan

bug#58520: Persistent failure to DNS-lookup hostname

[Visuwesh]

[வெள்ளி நவம்பர் 03, 2023] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

>>      3 Contacting host: search.brave.com:443
>>      4 search.brave.com/0 Temporary failure in name resolution
>>      5 cdn.search.brave.com/0 Temporary failure in name resolution
>>      6 cdn.search.brave.com/0 Temporary failure in name resolution
> [...]
>>     11 Contacting host: search.brave.com:443
>>     12 cdn.search.brave.com/0 Temporary failure in name resolution
>
>> Line nos. 1 and 2 are from url.el requests.  3--6 and 11--12 is from
>> connection to search.brave.com from eww for an internet search.
>
> Seems like the accesses failed just as well, so my guess is that the
> only thing different with EWW is that it falls back on a cache or
> something like that.

You might be right actually.  If I face this next time, I should search
something other than "asd."  If only eww recorded the time at which the
request was made...

bug#58520: Persistent failure to DNS-lookup hostname

[Visuwesh]

[சனி நவம்பர் 04, 2023] Visuwesh wrote:

> [வெள்ளி நவம்பர் 03, 2023] Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>>>      3 Contacting host: search.brave.com:443
>>>      4 search.brave.com/0 Temporary failure in name resolution
>>>      5 cdn.search.brave.com/0 Temporary failure in name resolution
>>>      6 cdn.search.brave.com/0 Temporary failure in name resolution
>> [...]
>>>     11 Contacting host: search.brave.com:443
>>>     12 cdn.search.brave.com/0 Temporary failure in name resolution
>>
>>> Line nos. 1 and 2 are from url.el requests.  3--6 and 11--12 is from(
>>> connection to search.brave.com from eww for an internet search.
>>
>> Seems like the accesses failed just as well, so my guess is that the
>> only thing different with EWW is that it falls back on a cache or
>> something like that.
>
> You might be right actually.  If I face this next time, I should search
> something other than "asd."  If only eww recorded the time at which the
> request was made...

And that fateful day arrived again.  AFAICT, eww does not seem to hold
any cache (at least that's what searching for the word "cache" leads me
to believe) but url.el does seem to have some caching mechanism.  I
evaluated the sexp

    (let ((url-cache-expire-time 0)) (url-cache-prune-cache))

and tried searching in eww again and it did that weird thing where the
request failed with the same error but still managed to render the page
in the end.

So far, I think that this issue has to do with the DNS changing and
Emacs somehow not being aware of it?  If I can trace the DNS server
being used in the end by Emacs that would help confirm this.  I will try
asking around to see if I can do this.

P.S. It would be nice to have that patch that you mentioned that added a
     function that fixes the broken requests.

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> P.S. It would be nice to have that patch that you mentioned that added a
>      function that fixes the broken requests.

I use the patch below.
When Emacs gets into this weird state, I do `M-: (res-init) RET` after
which I can connect again.


        Stefan


diff --git a/src/process.c b/src/process.c
index 8bc922ab509..56773fe192e 100644
--- a/src/process.c
+++ b/src/process.c
@@ -3770,6 +3769,33 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
   unbind_to (count, Qnil);
 }
 
+/* FIXME: Persistent DNS lookup errors!!
+ * Madhu <enometh@meer.net> suggests calling `res_init`, but that doesn't
+ * seem to exist any more in current glibc.
+ * Robert Pluim <rpluim@gmail.com> suggests to use
+ *
+ *    tcpdump -i any -n udp and port 53
+ *
+ * to try and see what requests are being sent out (if any) to where.
+ * Eli suggests checking systemwide DNS caches, pointing to:
+ *
+ *   https://devconnected.com/how-to-flush-dns-cache-on-linux/
+ *   https://beebom.com/how-flush-dns-cache-linux/
+ *   https://linuxize.com/post/how-to-clear-the-dns-cache/
+ *
+ * Relevant:
+ * https://sourceware.org/bugzilla/show_bug.cgi?id=984
+ */
+
+#include <resolv.h>
+
+DEFUN ("res-init", Fres_init, Sres_init, 0, 0, 0, doc: /* Run `res_init`.  */)
+  (void)
+{
+  res_init ();
+  return Qnil;
+}
+
 /* Create a network stream/datagram client/server process.  Treated
    exactly like a normal process when reading and writing.  Primary
    differences are in status display and process deletion.  A network
@@ -8821,6 +8849,7 @@ syms_of_process (void)
   defsubr (&Sserial_process_configure);
   defsubr (&Smake_serial_process);
   defsubr (&Sset_network_process_option);
+  defsubr (&Sres_init);
   defsubr (&Smake_network_process);
   defsubr (&Sformat_network_address);
   defsubr (&Snetwork_lookup_address_info);

bug#58520: Persistent failure to DNS-lookup hostname

[Eli Zaretskii]

> Cc: 58520@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 17 Dec 2023 18:27:10 -0500
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> > P.S. It would be nice to have that patch that you mentioned that added a
> >      function that fixes the broken requests.
> 
> I use the patch below.
> When Emacs gets into this weird state, I do `M-: (res-init) RET` after
> which I can connect again.

Why do you need Emacs for that?  Write a small program that calls
res_init, and that's it.

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Cc: 58520@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sun, 17 Dec 2023 18:27:10 -0500
>> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> > P.S. It would be nice to have that patch that you mentioned that added a
>> >      function that fixes the broken requests.
>> 
>> I use the patch below.
>> When Emacs gets into this weird state, I do `M-: (res-init) RET` after
>> which I can connect again.
>
> Why do you need Emacs for that?  Write a small program that calls
> res_init, and that's it.

I don't understand what you mean.  The problem is in the running Emacs
session, not in the overall system.  I'd have to write a separate
program that goes and "pokes" inside my running Emacs process, which
sounds quite complicated.

IOW, `res_init` only affects the running program.


        Stefan

bug#58520: Persistent failure to DNS-lookup hostname

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: visuweshm@gmail.com,  58520@debbugs.gnu.org,  eggert@cs.ucla.edu
> Date: Mon, 18 Dec 2023 12:41:00 -0500
> 
> IOW, `res_init` only affects the running program.

I didn't know that, sorry.  (I didn't know DNS can affect a single
program.)

If we want something like that in Emacs, we should probably find a
more portable way of doing it.

bug#58520: Persistent failure to DNS-lookup hostname

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> IOW, `res_init` only affects the running program.
> I didn't know that, sorry.  (I didn't know DNS can affect a single
> program.)

Basically, when the libc library parses the `/etc/resolv.conf` file to
figure out the IP address of the DNS server, it stores the result in
a local variable so as to speed up later DNS requests.
`res_init` forces it to reset that var.

It used to be indispensable to call it "all the time", but nowadays
glibc normally detects on its own when it needs to re-read
`/etc/resolv.conf`.

Except that in some weird corner case that Visuwesh and I are bumping
into, the "normally" fails to apply.  It's presumably a bug somewhere in
libc or in Emacs (or in some other library we use).

> If we want something like that in Emacs, we should probably find a
> more portable way of doing it.

I only used it to confirm the diagnostic, as well as as a crutch to
workaround the problem until it gets fixed.  So far I have not
considered including it in Emacs proper.


        Stefan