* Persistent failure to lookup hostname @ 2022-10-03 23:44 Stefan Monnier 2022-10-03 23:58 ` Lars Ingebrigtsen ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Stefan Monnier @ 2022-10-03 23:44 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-03 23:44 Persistent failure to lookup hostname Stefan Monnier @ 2022-10-03 23:58 ` Lars Ingebrigtsen 2022-10-04 0:15 ` Stefan Monnier 2022-10-04 3:40 ` Madhu 2022-10-04 6:51 ` Eli Zaretskii 2 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2022-10-03 23:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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... ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-03 23:58 ` Lars Ingebrigtsen @ 2022-10-04 0:15 ` Stefan Monnier 2022-10-04 7:37 ` Robert Pluim 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2022-10-04 0:15 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 0:15 ` Stefan Monnier @ 2022-10-04 7:37 ` Robert Pluim 2022-10-04 8:05 ` tomas 2022-10-04 13:27 ` Stefan Monnier 0 siblings, 2 replies; 18+ messages in thread From: Robert Pluim @ 2022-10-04 7:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 7:37 ` Robert Pluim @ 2022-10-04 8:05 ` tomas 2022-10-04 9:30 ` Robert Pluim 2022-10-04 13:27 ` Stefan Monnier 1 sibling, 1 reply; 18+ messages in thread From: tomas @ 2022-10-04 8:05 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 8:05 ` tomas @ 2022-10-04 9:30 ` Robert Pluim 2022-10-04 9:40 ` tomas 0 siblings, 1 reply; 18+ messages in thread From: Robert Pluim @ 2022-10-04 9:30 UTC (permalink / raw) To: tomas; +Cc: emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 9:30 ` Robert Pluim @ 2022-10-04 9:40 ` tomas 0 siblings, 0 replies; 18+ messages in thread From: tomas @ 2022-10-04 9:40 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 7:37 ` Robert Pluim 2022-10-04 8:05 ` tomas @ 2022-10-04 13:27 ` Stefan Monnier 2022-10-04 14:41 ` Robert Pluim 1 sibling, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2022-10-04 13:27 UTC (permalink / raw) To: Robert Pluim; +Cc: Lars Ingebrigtsen, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 13:27 ` Stefan Monnier @ 2022-10-04 14:41 ` Robert Pluim 2022-10-04 15:07 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Robert Pluim @ 2022-10-04 14:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: Lars Ingebrigtsen, emacs-devel >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 14:41 ` Robert Pluim @ 2022-10-04 15:07 ` Stefan Monnier 0 siblings, 0 replies; 18+ messages in thread From: Stefan Monnier @ 2022-10-04 15:07 UTC (permalink / raw) To: Robert Pluim; +Cc: Lars Ingebrigtsen, emacs-devel > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-03 23:44 Persistent failure to lookup hostname Stefan Monnier 2022-10-03 23:58 ` Lars Ingebrigtsen @ 2022-10-04 3:40 ` Madhu 2022-10-04 13:20 ` Stefan Monnier 2022-10-04 6:51 ` Eli Zaretskii 2 siblings, 1 reply; 18+ messages in thread From: Madhu @ 2022-10-04 3:40 UTC (permalink / raw) To: emacs-devel [-- 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; ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 3:40 ` Madhu @ 2022-10-04 13:20 ` Stefan Monnier 2022-10-06 19:56 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2022-10-04 13:20 UTC (permalink / raw) To: Madhu; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 13:20 ` Stefan Monnier @ 2022-10-06 19:56 ` Stefan Monnier 2022-10-14 15:53 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2022-10-06 19:56 UTC (permalink / raw) To: Madhu; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-06 19:56 ` Stefan Monnier @ 2022-10-14 15:53 ` Stefan Monnier 0 siblings, 0 replies; 18+ messages in thread From: Stefan Monnier @ 2022-10-14 15:53 UTC (permalink / raw) To: Madhu; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-03 23:44 Persistent failure to lookup hostname Stefan Monnier 2022-10-03 23:58 ` Lars Ingebrigtsen 2022-10-04 3:40 ` Madhu @ 2022-10-04 6:51 ` Eli Zaretskii 2022-10-04 13:24 ` Stefan Monnier 2 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-10-04 6:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 6:51 ` Eli Zaretskii @ 2022-10-04 13:24 ` Stefan Monnier 2022-10-04 13:53 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2022-10-04 13:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 13:24 ` Stefan Monnier @ 2022-10-04 13:53 ` Eli Zaretskii 2022-10-04 14:00 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-10-04 13:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Persistent failure to lookup hostname 2022-10-04 13:53 ` Eli Zaretskii @ 2022-10-04 14:00 ` Stefan Monnier 0 siblings, 0 replies; 18+ messages in thread From: Stefan Monnier @ 2022-10-04 14:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-10-14 15:53 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-03 23:44 Persistent failure to lookup hostname Stefan Monnier 2022-10-03 23:58 ` Lars Ingebrigtsen 2022-10-04 0:15 ` Stefan Monnier 2022-10-04 7:37 ` Robert Pluim 2022-10-04 8:05 ` tomas 2022-10-04 9:30 ` Robert Pluim 2022-10-04 9:40 ` tomas 2022-10-04 13:27 ` Stefan Monnier 2022-10-04 14:41 ` Robert Pluim 2022-10-04 15:07 ` Stefan Monnier 2022-10-04 3:40 ` Madhu 2022-10-04 13:20 ` Stefan Monnier 2022-10-06 19:56 ` Stefan Monnier 2022-10-14 15:53 ` Stefan Monnier 2022-10-04 6:51 ` Eli Zaretskii 2022-10-04 13:24 ` Stefan Monnier 2022-10-04 13:53 ` Eli Zaretskii 2022-10-04 14:00 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).