GNU bug report logs - #40748
28.0.50; Switching wifi networks hangs dns lookups

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40748 in the body.
You can then email your comments to 40748 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Switching wifi networks hangs dns lookups
Date: Tue, 21 Apr 2020 10:10:54 -0700

I'm on Emacs master, but this behavior has been evident for quite some
time, a year or two I think.

I often have trouble reconnecting Gnus' nntp servers after sleeping the
laptop in one location, and waking it up in another, connecting to a new
wifi network (I'm using Arch linux, if it matters).

I edebugged `nntp-open-connection', and realized that the error (which
is getting handled by `nnheader-report', that's why I didn't notice it)
is actually a dns error:

(error "news.gmane.io/nntp Temporary failure in name resol...")

Other Emacs network connections behave as normal. But this error for
this particular server persists until I restart Emacs.

Are DNS lookups cached? Cached per connection? Is there anything we can
do to flush whatever's "stuck"?

Here's the code that opens the connection; in my case it's
nntp-open-network-stream/network.

Happy to help with further debugging!

(let ((coding-system-for-read 'binary)
      (coding-system-for-write 'binary)
      (map '((nntp-open-network-stream network)
	     (network-only plain)	; compat
	     (nntp-open-plain-stream plain)
	     (nntp-open-ssl-stream tls)
	     (nntp-open-tls-stream tls))))
  (if (assoc nntp-open-connection-function map)
      (open-network-stream
       "nntpd" pbuffer nntp-address nntp-port-number
       :type (cadr (assoc nntp-open-connection-function map))
       :end-of-command "^\\([2345]\\|[.]\\).*\n"
       :capability-command "HELP\r\n"
       :success "^3"
       :starttls-function
       (lambda (capabilities)
	 (if (not (string-match "STARTTLS" capabilities))
	     nil
	   "STARTTLS\r\n")))
    (funcall nntp-open-connection-function pbuffer)))

Message #8 received at 40748 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Alexandrov <dag <at> gnui.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 40748 <at> debbugs.gnu.org
Subject: Re: bug#40748: 28.0.50; Switching wifi networks hangs dns lookups
Date: Fri, 03 Jul 2020 07:11:39 +0300

[Message part 1 (text/plain, inline)]

> I often have trouble reconnecting Gnus' nntp servers after sleeping the laptop in one location, and waking it up in another, connecting to a new wifi network

> I edebugged `nntp-open-connection', and realized that the error ‹…› is actually a dns error:

Looks familiar!

> Here's the code that opens the connection; in my case it's nntp-open-network-stream/network.

Could not it actually be an even deeper issue I outlined in bug#41234: 27.0.91; Synchronous network requests are failing with “Name or service not known” [1]?

[1] <mid:1rnogg6b.dag <at> gnui.org>
    <https://bugs.gnu.org/41234>

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 40748 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Alexandrov <dag <at> gnui.org>
Cc: 40748 <at> debbugs.gnu.org, 41234 <at> debbugs.gnu.org
Subject: Re: bug#40748: 28.0.50; Switching wifi networks hangs dns lookups
Date: Mon, 14 Jun 2021 16:02:02 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So I'm not sure how this can be an Emacs bug -- as far as I know,
> there's no way for libc clients to say "update all the DNS stuff now";
> it's supposed to happen automatically when you call getaddrinfo.  (If
> I'm wrong, somebody please correct me.)

This was almost a year ago -- does anybody have any further input here?
If not, I'm not sure there's anything we can do from the Emacs side
here...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #16 received at 40748 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40748 <at> debbugs.gnu.org, Dmitry Alexandrov <dag <at> gnui.org>,
 41234 <at> debbugs.gnu.org
Subject: Re: bug#40748: 28.0.50; Switching wifi networks hangs dns lookups
Date: Thu, 23 Dec 2021 14:09:48 -0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> So I'm not sure how this can be an Emacs bug -- as far as I know,
>> there's no way for libc clients to say "update all the DNS stuff now";
>> it's supposed to happen automatically when you call getaddrinfo.  (If
>> I'm wrong, somebody please correct me.)
>
> This was almost a year ago -- does anybody have any further input here?
> If not, I'm not sure there's anything we can do from the Emacs side
> here...

I do not, and it doesn't seem to be happening any more! My bug can be
closed, but I'm not sure about 41234, which it's been merged with.

Message #19 received at 40748 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 40748 <at> debbugs.gnu.org, Dmitry Alexandrov <dag <at> gnui.org>,
 41234 <at> debbugs.gnu.org
Subject: Re: bug#40748: 28.0.50; Switching wifi networks hangs dns lookups
Date: Fri, 24 Dec 2021 10:11:54 +0100

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I do not, and it doesn't seem to be happening any more! My bug can be
> closed, but I'm not sure about 41234, which it's been merged with.

I think that bug report points to a problem somewhere else in the OS and
not in Emacs, so I'm closing this bug report.  If this is wrong, please
respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.