bug#41234: 27.0.91; Synchronous network requests are failing with “Name or service not known”

bug#41234: 27.0.91; Synchronous network requests are failing with “Name or service not known”

[Dmitry Alexandrov]

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

Dear maintainers,

Iʼm not sure whether that a bugreport or a support request, I hope you will excuse me for opting for the former.

Basically, I have an instance of Emacs 27 — rev. aea1b4db72 — a head of emacs-27 from about two weeks ago, which, have been running for that time, is failing to resolve any remote hostname synchronously (which, for instance, Gnus normally does), while asynchronous requests (as in ‘url-retrieve’) are still working fine.

A newly started instance of the same Emacs does not demonstrate the issue.  And alas, despite being almost convinced, that I had already met this problem before, I cannot say how exactly to reproduce it.

However, I suppose, the fact, that this is by no means a pristine configuration is not much relevant, since the error goes down to C sources, namely to ‘make-network-process’:

	(make-network-process :name " *net-test*"
						  :buffer (get-buffer-create " *net-test*")
						  :host "gnu.org" :service 80
						  :nowait nil)
	;; Debugger entered--Lisp error: (error "gnu.org/80 Name or service not known")

More specifically, a call to getaddrinfo() in ‘network_lookup_address_info_1’ returns EAI_NONAME.

Could it be a problem in GNU Emacs, or have I broken my system somehow?

-- 
In GNU Emacs 27.0.91 (build 2, x86_64-pc-linux-gnu)
 of 2020-04-30 built on nora
Repository revision: aea1b4db72df92595a3f642d18bf57254d74772b
Repository branch: emacs-27-nightly
System Description: Debian GNU/Linux 10 (buster)

Configured using:
 'configure --with-x-toolkit=no'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB OLDXMENU X11 XDBE XIM MODULES THREADS LIBSYSTEMD PDUMPER LCMS2 GMP

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

bug#41234: 27.0.91; Synchronous network requests are failing with “Name or service not known”

[Dmitry Alexandrov]

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

FWIW, strace suggests, that the problematic Emacs process is trying to connect to an outdated nameserver (from a LAN this machine was connected once):

	…
	openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 12
	lseek(12, 0, SEEK_CUR)                  = 0
	fstat(12, {st_mode=S_IFREG|0644, st_size=184, ...}) = 0
	read(12, "127.0.0.1\tlocalhost\n127.0.1.1\tno"..., 4096) = 184
	lseek(12, 0, SEEK_CUR)                  = 184
	read(12, "", 4096)                      = 0
	close(12)                               = 0
	socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 12
	connect(12, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, 16) = 0
	gettimeofday({tv_sec=1589546464, tv_usec=72520}, NULL) = 0
	poll([{fd=12, events=POLLOUT}], 1, 0)   = 1 ([{fd=12, revents=POLLOUT}])
	sendto(12, "`\t\1\0\0\1\0\0\0\0\0\0\3gnu\3org\0\0\1\0\1", 25, MSG_NOSIGNAL, NULL, 0) = 25
	…

That is, that /etc/resolv.conf had not been reread (there is nothing about it in the skipped output above), while the instance that is working fine do check whether /etc/resolv.conf is updated:

	…
	stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=56, ...}) = 0
	openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 11
	lseek(11, 0, SEEK_CUR)                  = 0
	fstat(11, {st_mode=S_IFREG|0644, st_size=184, ...}) = 0
	read(11, "127.0.0.1\tlocalhost\n127.0.1.1\tno"..., 4096) = 184
	lseek(11, 0, SEEK_CUR)                  = 184
	read(11, "", 4096)                      = 0
	close(11)                               = 0
	socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 11
	connect(11, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.43.223")}, 16) = 0
	gettimeofday({tv_sec=1589546877, tv_usec=860209}, NULL) = 0
	poll([{fd=11, events=POLLOUT}], 1, 0)   = 1 ([{fd=11, revents=POLLOUT}])
	sendmmsg(11, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\314\255\1\0\0\1\0\0\0\0\0\0\3gnu\3org\0\0\1\0\1", iov_len=25}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=25}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\10\270\1\0\0\1\0\0\0\0\0\0\3gnu\3org\0\0\34\0\1", iov_len=25}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=25}], 2, MSG_NOSIGNAL) = 2
	…

How should I interpret this?

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

bug#41234: 27.0.91; Synchronous network requests are failing with “Name or service not known”

[Dmitry Alexandrov]

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

found 41234 28.0.50
thanks

Dmitry Alexandrov <dag@gnui.org> wrote:
> FWIW, strace suggests, that the problematic Emacs process is trying to connect to an outdated nameserver (from a LAN this machine was connected once):

> That is, that /etc/resolv.conf had not been reread...

Heh.  Emacs is able to lost running nscd(8) and fall back to outdated nameserver as well:

        …
	openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 7
	lseek(7, 0, SEEK_CUR)                   = 0
	fstat(7, {st_mode=S_IFREG|0644, st_size=184, ...}) = 0
	read(7, "127.0.0.1\tlocalhost\n127.0.1.1\tno"..., 4096) = 184
	lseek(7, 0, SEEK_CUR)                   = 184
	read(7, "", 4096)                       = 0
	close(7)                                = 0
	socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 7
	connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.43.245")}, 16) = 0
	gettimeofday({tv_sec=1593704775, tv_usec=183050}, NULL) = 0
	poll([{fd=7, events=POLLOUT}], 1, 0)    = 1 ([{fd=7, revents=POLLOUT}])
	sendto(7, "\254o\1\0\0\1\0\0\0\0\0\0\3gnu\3org\0\0\1\0\1", 25, MSG_NOSIGNAL, NULL, 0) = 25
        …

— thatʼs instead of:

        …
	socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 10
	connect(10, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = 0
	sendto(10, "\2\0\0\0\16\0\0\0\t\0\0\0gnus.org\0", 21, MSG_NOSIGNAL, NULL, 0) = 21
        …

in a freshly started Emacs instance.

Perhaps, I have to try another workaround.

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

bug#41234: 27.0.91; Synchronous network requests are failing with “Name or service not known”

[Lars Ingebrigtsen]

Dmitry Alexandrov <dag@gnui.org> writes:

> 	(make-network-process :name " *net-test*"
> 						  :buffer (get-buffer-create " *net-test*")
> 						  :host "gnu.org" :service 80
> 						  :nowait nil)
> 	;; Debugger entered--Lisp error: (error "gnu.org/80 Name or service not known")
>
> More specifically, a call to getaddrinfo() in ‘network_lookup_address_info_1’ returns EAI_NONAME.
>
> Could it be a problem in GNU Emacs, or have I broken my system somehow?

Dmitry Alexandrov <dag@gnui.org> writes:

> FWIW, strace suggests, that the problematic Emacs process is trying to
> connect to an outdated nameserver (from a LAN this machine was
> connected once):

[...]

> That is, that /etc/resolv.conf had not been reread (there is nothing
> about it in the skipped output above), while the instance that is
> working fine do check whether /etc/resolv.conf is updated:

Hm...   since the async lookups work, I guess this means that
getaddrinfo_a works, but getaddrinfo doesn't?  Which is very odd -- both
functions are supposed to update the name server etc in the same way, I
think?

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

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

bug#40748: 28.0.50; Switching wifi networks hangs dns lookups

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#40748: 28.0.50; Switching wifi networks hangs dns lookups

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@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.

bug#41234: bug#40748: 28.0.50; Switching wifi networks hangs dns lookups

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@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

bug#40748: 28.0.50; Switching wifi networks hangs dns lookups

[Eric Abrahamsen]

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

bug#40748: 28.0.50; Switching wifi networks hangs dns lookups

[Dmitry Alexandrov]

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

> 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@gnui.org>
    <https://bugs.gnu.org/41234>

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