Persistent failure to lookup hostname

Persistent failure to lookup hostname

[Stefan Monnier]

Hi,

My Gnus session occasionally gets into a state where it insists that my
mail server's DNS name isn't found.  I haven't yet managed to get close
to the source of the problem, in large part because I don't know how to
reproduce it.  It seems to be associated with network failures (or
captive portals, which are basically purposefully broken networks).

That a DNS lookup would fail while the network is having problem is of
course normal, but the problem is that the failure seems to persist "for
ever", or more specifically until I restart Emacs.  E.g. the old Gnus
sessions will keep giving me a hostname error while at the very same
time all other processes on the system (Firefox, `host`, a fresh new
Emacs, you name it) have no problem finding the IP address of (and even
connecting to) the very same host.

The last two times this occurred I tried to look a bit more into it, but
I realized that I don't know enough about how this works to know where
to look.

The error itself is signaled by `make-network-process` and I suspect the
error is actually raised by the following piece of code (tho I couldn't
confirm it because I somehow ended up killing the process while trying to
attach GDB to it):

      msg = network_lookup_address_info_1 (host, portstring, &hints, &res);
      if (!EQ (msg, Qt))
	error ("%s", SSDATA (msg));

Looking at `network_lookup_address_info_1` it seems it doesn't do much
more than call `getaddrinfo` (I couldn't copy&paste the actual error
message but it basically contains my host name plus some error message
in French, which seems consistent with an error message taken straight
from `gai_strerror`).

Does anyone here have an idea why `getaddrinfo` might return an outdated
error, or whether it could come from elsewhere?  Or how/where I might
find a kind of DNS cache that would be process-local rather
than systemwide?

Or any other hint?


        Stefan

Re: Persistent failure to lookup hostname

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> My Gnus session occasionally gets into a state where it insists that my
> mail server's DNS name isn't found.

Is this with nnimap?  (I'm mostly just wondering whether this could
somehow be tied to the async code paths, which are more complicated than
the synchronous code paths and keep more state -- but nnimap doesn't use
async, so that would rule out that.)

> Does anyone here have an idea why `getaddrinfo` might return an outdated
> error, or whether it could come from elsewhere?  Or how/where I might
> find a kind of DNS cache that would be process-local rather
> than systemwide?

Doesn't ring any bells -- I didn't think there was a per-process DNS
cache either, but who knows these days with modern glibc/systemd...

Re: Persistent failure to lookup hostname

[Stefan Monnier]

Lars Ingebrigtsen [2022-10-04 01:58:28] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> My Gnus session occasionally gets into a state where it insists that my
>> mail server's DNS name isn't found.
> Is this with nnimap?  (I'm mostly just wondering whether this could
> somehow be tied to the async code paths, which are more complicated than
> the synchronous code paths and keep more state -- but nnimap doesn't use
> async, so that would rule out that.)

Hmm... yes, I think it's always been for my IMAP server.


        Stefan

Re: Persistent failure to lookup hostname

[Madhu]

[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]

* Stefan Monnier <jwvfsg4v66f.fsf-monnier+emacs@gnu.org> :
Wrote on Mon, 03 Oct 2022 19:44:29 -0400:
> My Gnus session occasionally gets into a state where it insists that my
> mail server's DNS name isn't found.  I haven't yet managed to get close
> to the source of the problem, in large part because I don't know how to
> reproduce it.  It seems to be associated with network failures (or
> captive portals, which are basically purposefully broken networks).
>
> That a DNS lookup would fail while the network is having problem is of
> course normal, but the problem is that the failure seems to persist "for
> ever", or more specifically until I restart Emacs.  E.g. the old Gnus
> sessions will keep giving me a hostname error while at the very same
> time all other processes on the system (Firefox, `host`, a fresh new
> Emacs, you name it) have no problem finding the IP address of (and even
> connecting to) the very same host.
>
> The last two times this occurred I tried to look a bit more into it, but
> I realized that I don't know enough about how this works to know where
> to look.
>
> The error itself is signaled by `make-network-process` and I suspect the
> error is actually raised by the following piece of code (tho I couldn't
> confirm it because I somehow ended up killing the process while trying to
> attach GDB to it):
>
>       msg = network_lookup_address_info_1 (host, portstring, &hints, &res);
>       if (!EQ (msg, Qt))
> 	error ("%s", SSDATA (msg));
>
> Looking at `network_lookup_address_info_1` it seems it doesn't do much
> more than call `getaddrinfo` (I couldn't copy&paste the actual error
> message but it basically contains my host name plus some error message
> in French, which seems consistent with an error message taken straight
> from `gai_strerror`).
>
> Does anyone here have an idea why `getaddrinfo` might return an outdated
> error, or whether it could come from elsewhere?  Or how/where I might
> find a kind of DNS cache that would be process-local rather
> than systemwide?

* commit:   commit 93bf7d52841c60ffc10e0c9c789a7987812ce55e
|            Author:     Paul Eggert <eggert@cs.ucla.edu>
|            AuthorDate: Mon Feb 29 09:39:45 2016 -0800
|            Commit:     Paul Eggert <eggert@cs.ucla.edu>
|            CommitDate: Mon Feb 29 09:40:58 2016 -0800
|
|  Stop calling res_init
|
|  Emacs shouldn’t need to call res_init any more, now that nscd or
|  equivalent is everywhere.  On modern systems, calling res_init simply
|  slows Emacs down.  On ancient systems lacking nscd Emacs will still
|  work well enough with this change; it’s just that it won’t respond to
|  changes in /etc/resolv.conf


Perhaps the expected results result from changes to resolv.conf, and you
aren't running glibc's nscd (I don't because it generates a lot of bogus
traffic)

The attached patch reverts that commit and reinstates res_init, maybe
you could try it to see if it helps


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: reinstate res_init --]
[-- Type: text/x-patch, Size: 4210 bytes --]

diff --git a/admin/CPP-DEFINES b/admin/CPP-DEFINES
index 06986ec8f48..a9860608076 100644
--- a/admin/CPP-DEFINES
+++ b/admin/CPP-DEFINES
@@ -236,6 +236,7 @@ HAVE_RANDOM
 HAVE_READLINK
 HAVE_READLINKAT
 HAVE_RECVFROM
+HAVE_RES_INIT
 HAVE_RINT
 HAVE_RSVG
 HAVE_SELECT
diff --git a/configure.ac b/configure.ac
index 4590ed3506e..38530f19ed3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5167,13 +5167,44 @@ AC_DEFUN
      [emacs_cv_alternate_stack=yes],
      [emacs_cv_alternate_stack=no])])
 
+# Do we have res_init, for detecting changes in /etc/resolv.conf?
+# On Darwin, res_init appears not to be useful: see bug#562 and
+# http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01467.html
+resolv=no
+
+if test $opsys != darwin; then
+
+  AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <netinet/in.h>
+#include <arpa/nameser.h>
+#include <resolv.h>]],
+    [[return res_init();]])],
+    have_res_init=yes, have_res_init=no)
+  if test "$have_res_init" = no; then
+    OLIBS="$LIBS"
+    LIBS="$LIBS -lresolv"
+    AC_MSG_CHECKING(for res_init with -lresolv)
+    AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <netinet/in.h>
+#include <arpa/nameser.h>
+#include <resolv.h>]],
+      [[return res_init();]])],
+      have_res_init=yes, have_res_init=no)
+    AC_MSG_RESULT($have_res_init)
+    if test "$have_res_init" = yes ; then
+      resolv=yes
+    fi
+    LIBS="$OLIBS"
+  fi
+
+  if test "$have_res_init" = yes; then
+    AC_DEFINE(HAVE_RES_INIT, 1, [Define to 1 if res_init is available.])
+  fi
+fi                              dnl !darwin
+
 # Do we need the Hesiod library to provide the support routines?
 dnl FIXME?  Should we be skipping this on Darwin too?
 LIBHESIOD=
-LIBRESOLV=
 if test "$with_hesiod" != no ; then
   # Don't set $LIBS here -- see comments above.  FIXME which comments?
-  resolv=no
   AC_CHECK_FUNC([res_send], [], [AC_CHECK_FUNC([__res_send], [],
      [AC_CHECK_LIB([resolv], [res_send], [resolv=yes],
 		  [AC_CHECK_LIB([resolv], [__res_send], [resolv=yes])])])])
@@ -5189,10 +5220,16 @@ AC_DEFUN
 
   if test x"$hesiod" = xyes; then
     LIBHESIOD=-lhesiod
-    LIBRESOLV=$RESOLVLIB
   fi
 fi
 AC_SUBST([LIBHESIOD])
+
+# Do we need libresolv (due to res_init or Hesiod)?
+if test "$resolv" = yes && test $opsys != darwin; then
+  LIBRESOLV=-lresolv
+else
+  LIBRESOLV=
+fi
 AC_SUBST([LIBRESOLV])
 
 # These tell us which Kerberos-related libraries to use.
diff --git a/src/Makefile.in b/src/Makefile.in
index 1f941874ea8..e0375b43205 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -331,6 +331,9 @@ CM_OBJ=
 
 LIBGPM = @LIBGPM@
 
+## -lresolv, or empty.
+LIBRESOLV = @LIBRESOLV@
+
 LIBSELINUX_LIBS = @LIBSELINUX_LIBS@
 
 LIBGNUTLS_LIBS = @LIBGNUTLS_LIBS@
@@ -559,7 +562,7 @@ LIBES =
    $(LIB_EACCESS) $(LIB_TIMER_TIME) $(DBUS_LIBS) \
    $(LIB_EXECINFO) $(XRANDR_LIBS) $(XINERAMA_LIBS) $(XFIXES_LIBS) \
    $(XDBE_LIBS) $(XSYNC_LIBS) \
-   $(LIBXML2_LIBS) $(LIBGPM) $(LIBS_SYSTEM) $(CAIRO_LIBS) \
+   $(LIBXML2_LIBS) $(LIBGPM) $(LIBRESILV) $(LIBS_SYSTEM) $(CAIRO_LIBS) \
    $(LIBS_TERMCAP) $(GETLOADAVG_LIBS) $(SETTINGS_LIBS) $(LIBSELINUX_LIBS) \
    $(FREETYPE_LIBS) $(FONTCONFIG_LIBS) $(HARFBUZZ_LIBS) $(LIBOTF_LIBS) $(M17N_FLT_LIBS) \
    $(LIBGNUTLS_LIBS) $(LIB_PTHREAD) $(GETADDRINFO_A_LIBS) $(LCMS2_LIBS) \
diff --git a/src/process.c b/src/process.c
index 9dfb98d8f38..8e4a27fd16b 100644
--- a/src/process.c
+++ b/src/process.c
@@ -83,6 +83,11 @@ #define HAVE_LOCAL_SOCKETS
 
 #endif
 
+#ifdef HAVE_RES_INIT
+#include <arpa/nameser.h>
+#include <resolv.h>
+#endif
+
 #ifdef HAVE_UTIL_H
 #include <util.h>
 #endif
@@ -4137,6 +4142,9 @@ DEFUN ("make-network-process", Fmake_network_process, Smake_network_process,
 	  strcpy (req->str, SSDATA (host));
 	  strcpy (req->str + hostlen + 1, portstring);
 
+#ifdef HAVE_RES_INIT
+    res_init ();
+#endif
 	  int ret = getaddrinfo_a (GAI_NOWAIT, &dns_request, 1, NULL);
 	  if (ret)
 	    error ("%s/%s getaddrinfo_a error %d",
@@ -4157,6 +4165,10 @@ DEFUN ("make-network-process", Fmake_network_process, Smake_network_process,
 
       maybe_quit ();
 
+#ifdef HAVE_RES_INIT
+      res_init ();
+#endif
+
       struct addrinfo hints;
       memset (&hints, 0, sizeof hints);
       hints.ai_family = family;

Re: Persistent failure to lookup hostname

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 03 Oct 2022 19:44:29 -0400
> 
> Does anyone here have an idea why `getaddrinfo` might return an outdated
> error, or whether it could come from elsewhere?  Or how/where I might
> find a kind of DNS cache that would be process-local rather
> than systemwide?

Is it certain that the problem is specific to that single process?
Did you try flushing and renewing the system's DNS cache with the
appropriate shell commands?

Re: Persistent failure to lookup hostname

[Robert Pluim]

>>>>> On Mon, 03 Oct 2022 20:15:19 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> Lars Ingebrigtsen [2022-10-04 01:58:28] wrote:
    >> Stefan Monnier <monnier@iro.umontreal.ca> writes:
    >>> My Gnus session occasionally gets into a state where it insists that my
    >>> mail server's DNS name isn't found.
    >> Is this with nnimap?  (I'm mostly just wondering whether this could
    >> somehow be tied to the async code paths, which are more complicated than
    >> the synchronous code paths and keep more state -- but nnimap doesn't use
    >> async, so that would rule out that.)

    Stefan> Hmm... yes, I think it's always been for my IMAP server.

One thing you absolutely need to check in these situations is if DNS queries
are making it out of Emacs at all. e.g.

    sudo tcpdump -i any -n udp and port 53

If theyʼre not, then maybe itʼs an issue with resolv.conf, as Madhu
suggests.

Robert
-- 

Re: Persistent failure to lookup hostname

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

On Tue, Oct 04, 2022 at 09:37:53AM +0200, Robert Pluim wrote:
> >>>>> On Mon, 03 Oct 2022 20:15:19 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:
> 
>     Stefan> Lars Ingebrigtsen [2022-10-04 01:58:28] wrote:
>     >> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>     >>> My Gnus session occasionally gets into a state where it insists that my
>     >>> mail server's DNS name isn't found.
>     >> Is this with nnimap?  (I'm mostly just wondering whether this could
>     >> somehow be tied to the async code paths, which are more complicated than
>     >> the synchronous code paths and keep more state -- but nnimap doesn't use
>     >> async, so that would rule out that.)
> 
>     Stefan> Hmm... yes, I think it's always been for my IMAP server.
> 
> One thing you absolutely need to check in these situations is if DNS queries
> are making it out of Emacs at all. e.g.
> 
>     sudo tcpdump -i any -n udp and port 53

"Out of Emacs" can mean different things :)

E.g. if nscd is active, that's a caching layer somewhere at libc level (so
Emacs won't be aware of it, but the request won't hit the net, so tcpdump
won't see it). Also, for the young-uns, systemd is said to do DNS caching
itself too (what doesn't it do?), but I can't test that due to lack of
systemd ;-) That one, possibly, is also in limbo between Emacs and what
tcpdump can see (but also possibly, not).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Persistent failure to lookup hostname

[Robert Pluim]

>>>>> On Tue, 4 Oct 2022 10:05:29 +0200, <tomas@tuxteam.de> said:

    tomas> On Tue, Oct 04, 2022 at 09:37:53AM +0200, Robert Pluim wrote:
    >> sudo tcpdump -i any -n udp and port 53

    tomas> "Out of Emacs" can mean different things :)

    tomas> E.g. if nscd is active, that's a caching layer somewhere at libc level (so
    tomas> Emacs won't be aware of it, but the request won't hit the net, so tcpdump
    tomas> won't see it). Also, for the young-uns, systemd is said to do DNS caching
    tomas> itself too (what doesn't it do?), but I can't test that due to lack of
    tomas> systemd ;-) That one, possibly, is also in limbo between Emacs and what
    tomas> tcpdump can see (but also possibly, not).

Yes, and then there is dnsmasq, and the upstream DSL 'routerʼ might be
caching DNS, etc etc. Checking the network traffix just helps in
finding out who to blame :-)

Robert
-- 

Re: Persistent failure to lookup hostname

[tomas]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Tue, Oct 04, 2022 at 11:30:08AM +0200, Robert Pluim wrote:
> >>>>> On Tue, 4 Oct 2022 10:05:29 +0200, <tomas@tuxteam.de> said:
> 
>     tomas> On Tue, Oct 04, 2022 at 09:37:53AM +0200, Robert Pluim wrote:
>     >> sudo tcpdump -i any -n udp and port 53
> 
>     tomas> "Out of Emacs" can mean different things :)

[...]

> Yes, and then there is dnsmasq, and the upstream DSL 'routerʼ might be
> caching DNS, etc etc. Checking the network traffix just helps in
> finding out who to blame :-)

You would see the latter with tcpdump (make sure to include local
interfaces to catch dnsmasq). But you wouldn't catch nscd (no network
traffic) and possibly not systemd-resolved or how it's called.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Persistent failure to lookup hostname

[Stefan Monnier]

Madhu [2022-10-04 09:10:07] wrote:
> Perhaps the expected results result from changes to resolv.conf, and you
> aren't running glibc's nscd (I don't because it generates a lot of bogus
> traffic)
[...]
> The attached patch reverts that commit and reinstates res_init, maybe
> you could try it to see if it helps

Oh that sounds promising (according to `ps` I'm not running `nscd` on
that machine either, tho it was not a conscious choice).
I'll see if I can export `res_init` to ELisp and then check if calling
it unwedges my session next time it occurs!

Thanks!


        Stefan

Re: Persistent failure to lookup hostname

[Stefan Monnier]

Eli Zaretskii [2022-10-04 09:51:44] wrote:
>> Does anyone here have an idea why `getaddrinfo` might return an outdated
>> error, or whether it could come from elsewhere?  Or how/where I might
>> find a kind of DNS cache that would be process-local rather
>> than systemwide?
> Is it certain that the problem is specific to that single process?

No.  But it's certain that it's not system-wide because all the other
processes (including a fresh new Emacs session, and an older Emacs
session that rarely/never uses network connections) I tried had no
problem resolving that same address.

It very definitely looks specific to that process.

> Did you try flushing and renewing the system's DNS cache with the
> appropriate shell commands?

I don't know that I have such a thing on this system.


        Stefan

Re: Persistent failure to lookup hostname

[Stefan Monnier]

Robert Pluim [2022-10-04 09:37:53] wrote:
>>>>>> On Mon, 03 Oct 2022 20:15:19 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:
>     Stefan> Lars Ingebrigtsen [2022-10-04 01:58:28] wrote:
>     >> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>     >>> My Gnus session occasionally gets into a state where it insists that my
>     >>> mail server's DNS name isn't found.
>     >> Is this with nnimap?  (I'm mostly just wondering whether this could
>     >> somehow be tied to the async code paths, which are more complicated than
>     >> the synchronous code paths and keep more state -- but nnimap doesn't use
>     >> async, so that would rule out that.)
>
>     Stefan> Hmm... yes, I think it's always been for my IMAP server.
>
> One thing you absolutely need to check in these situations is if DNS queries
> are making it out of Emacs at all. e.g.
>
>     sudo tcpdump -i any -n udp and port 53
>
> If theyʼre not, then maybe itʼs an issue with resolv.conf, as Madhu
> suggests.

Indeed, they may also be sent to "the wrong" nameserver (e.g. the
nameserver that was to be used back when I was working in that café the
other day).

Thanks,


        Stefan

Re: Persistent failure to lookup hostname

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Tue, 04 Oct 2022 09:24:36 -0400
> 
> Eli Zaretskii [2022-10-04 09:51:44] wrote:
> >> Does anyone here have an idea why `getaddrinfo` might return an outdated
> >> error, or whether it could come from elsewhere?  Or how/where I might
> >> find a kind of DNS cache that would be process-local rather
> >> than systemwide?
> > Is it certain that the problem is specific to that single process?
> 
> No.  But it's certain that it's not system-wide because all the other
> processes (including a fresh new Emacs session, and an older Emacs
> session that rarely/never uses network connections) I tried had no
> problem resolving that same address.

You are saying that the affected Emacs session cannot use eww or any
of the url code to access sites (or just that IMAP site)?

> > Did you try flushing and renewing the system's DNS cache with the
> > appropriate shell commands?
> 
> I don't know that I have such a thing on this system.

Could be.  Maybe the next links will help:

  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/

Re: Persistent failure to lookup hostname

[Stefan Monnier]

>> No.  But it's certain that it's not system-wide because all the other
>> processes (including a fresh new Emacs session, and an older Emacs
>> session that rarely/never uses network connections) I tried had no
>> problem resolving that same address.
> You are saying that the affected Emacs session cannot use eww or any
> of the url code to access sites (or just that IMAP site)?

That's a good question, I should check that as well next time,
indeed, thanks.

[ Not sure why it didn't occur to me back then.  Apparently I was
  looking for ways to get my IMAP connection working more than for ways
  to diagnose the problem.  ]

>> > Did you try flushing and renewing the system's DNS cache with the
>> > appropriate shell commands?
>> I don't know that I have such a thing on this system.
> Could be.  Maybe the next links will help:
>
>   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/

I did check for `nscd` and I know it's not running `dnsmasq` any more no
that machine (I know because I used to run it), but I haven't checked
`systemd-resolved` yet.

Thanks.


        Stefan

Re: Persistent failure to lookup hostname

[Robert Pluim]

>>>>> On Tue, 04 Oct 2022 09:27:03 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> Indeed, they may also be sent to "the wrong" nameserver (e.g. the
    Stefan> nameserver that was to be used back when I was working in that café the
    Stefan> other day).

Thatʼs why some of the GNU/Linux dns implementations have a
resolv.conf that points you at localhost, and then they run a daemon
that takes care of the actual DNS queries and updating the resolver
IPs (I have a vague memory of dnsmasq doing that, and maybe
systemd-resolvd, but I have no such abominations on my system 😀)

Robert
-- 

Re: Persistent failure to lookup hostname

[Stefan Monnier]

> Thatʼs why some of the GNU/Linux dns implementations have a
> resolv.conf that points you at localhost, and then they run a daemon
> that takes care of the actual DNS queries and updating the resolver
> IPs (I have a vague memory of dnsmasq doing that, and maybe
> systemd-resolvd, but I have no such abominations on my system 😀)

Hey!  I like Dnsmasq!


        Stefan

Re: Persistent failure to lookup hostname

[Stefan Monnier]

Stefan Monnier [2022-10-04 09:20:47] wrote:
> Madhu [2022-10-04 09:10:07] wrote:
>> Perhaps the expected results result from changes to resolv.conf, and you
>> aren't running glibc's nscd (I don't because it generates a lot of bogus
>> traffic)
> [...]
>> The attached patch reverts that commit and reinstates res_init, maybe
>> you could try it to see if it helps
>
> Oh that sounds promising (according to `ps` I'm not running `nscd` on
> that machine either, tho it was not a conscious choice).
> I'll see if I can export `res_init` to ELisp and then check if calling
> it unwedges my session next time it occurs!

Hmm... apparently `res_init` doesn't even exist any more in
current glibc :-(


        Stefan

Re: Persistent failure to lookup hostname

[Stefan Monnier]

Stefan Monnier [2022-10-06 15:56:21] wrote:
> Stefan Monnier [2022-10-04 09:20:47] wrote:
>> Madhu [2022-10-04 09:10:07] wrote:
>>> Perhaps the expected results result from changes to resolv.conf, and you
>>> aren't running glibc's nscd (I don't because it generates a lot of bogus
>>> traffic)
>> [...]
>>> The attached patch reverts that commit and reinstates res_init, maybe
>>> you could try it to see if it helps
>>
>> Oh that sounds promising (according to `ps` I'm not running `nscd` on
>> that machine either, tho it was not a conscious choice).
>> I'll see if I can export `res_init` to ELisp and then check if calling
>> it unwedges my session next time it occurs!
>
> Hmm... apparently `res_init` doesn't even exist any more in
> current glibc :-(

Nope, apparently it's just that you need `#include <resolv.h>`
before it "appears".


        Stefan