test: Error: getaddrinfo ENOTFOUND localhost #44003
Comments
|
curious what you see when doing $ strace -ff ./node test/parallel/test-tcp-wrap-listen.js |& grep localhost
[pid 4385] read(19, "127.0.0.1 localhost\n\n# The follo"..., 4096) = 221
[pid 4385] sendto(19, "\362*\1 \0\1\0\0\0\0\0\1\tlocalhost\3ec2\10inter"..., 51, MSG_NOSIGNAL, NULL, 0) = 51
[pid 4385] recvfrom(19, "\362*\201\203\0\1\0\0\0\0\0\1\tlocalhost\3ec2\10inter"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 51
[pid 4385] sendto(19, "Uk\1 \0\1\0\0\0\0\0\1\tlocalhost\0\0\34\0\1\0\0)\4\260"..., 38, MSG_NOSIGNAL, NULL, 0) = 38
[pid 4385] recvfrom(19, "Uk\205\240\0\1\0\1\0\0\0\1\tlocalhost\0\0\34\0\1\300\f\0\34\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 66 |
|
I get this error sometimes on my pc, but not always. |
|
ENOTFOUND is a synthetic error that node fabricates when it doesn't get an answer back from getaddrinfo(3), it's not a real operating system-level error. Reasons include running out of file descriptors in libc (not visible to node), not getting back a response from the DNS server, etc. It's basically a catch-all. |
|
In this case, there is no DNS server and it works with other tests... strace shows nothing. This is only a problem since about 18.2.0 and not before and not in any other released line. And I only see it in a VM build environment and not in a chroot (at least it disappeared there) which is very strange. I will try to bisect the issue. |
|
You mean v18.1.0 works? There are no changes between the two that seem like likely culprits. I'm interested to see what bisect turns up. |
|
So, the bisect ended up on 70b516e which is #43054 . Looking at the pull request, it kind of makes sense this is the one as the tests in question are explicitly skipped on some platforms. The test is reproducible every time on openSUSE:Tumbleweed build VM. I can't reproduce it outside of it on a workstation, but in the VM with no networking connections and only a hosts file to resolve localhost to ipv6 and ipv4, it reproduces every time. I will try to look more closely what is actually failing here. |
|
This was introduced in 18.4.0. I mistyped earlier the versions. 18.2.0 still passed |
|
Is there no network interface at all, no loopback ? |
As a consequence of nodejs#43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: nodejs#44003
|
So, I've learned something about debugging node over last few days :-) But I did find the problem. The problem is that family is set to a string, which causes hints to be set to 32 which means AI_ADDRCONFIG and then address resolution fails. On a network connected device, this passes. Why? We can look at the manpage for
This is why these tests fail every time when you have a loopback interface as the only network interface active. They will pass if you have other network interfaces active. |
As a consequence of nodejs#43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results in wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: nodejs#44003
As a consequence of #43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results in wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: #44003 PR-URL: #44083 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
As a consequence of #43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results in wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: #44003 PR-URL: #44083 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
As a consequence of #43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results in wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: #44003 PR-URL: #44083 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
As a consequence of nodejs#43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results in wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: nodejs#44003 PR-URL: nodejs#44083 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
As a consequence of #43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results in wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: #44003 PR-URL: #44083 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
As a consequence of #43014 , server sockets and others, once connected, report string family names. But when feeding these to Socket.connect(), it passes these to host resolution with a string for family while a numeric family is expected internally. This results in wrong hints flags to be set and resolution to fail. As solution, is to add ability to handle both numeric and string family names when doing lookup and connect. Fixes: #44003 PR-URL: #44083 Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
|
original: Error: getaddrinfo ENOTFOUND undefined el error aca como podria solucionar? me arroja basicamente que no encuentra mi localhost. |
|
In my case, the same error occurred when I made a request to a server address other than localhost, but it turned out that there was no problem with me and the problem was with the server. |
|
I add the line in my hosts file and it worked;
|
Version
18.6.0
Platform
openSUSE Tumbleweed
Subsystem
No response
What steps will reproduce the bug?
Currently the failures are visible in the current build log,
https://build.opensuse.org/public/build/devel:languages:nodejs/openSUSE_Tumbleweed/x86_64/nodejs18/_log
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
No response
What do you see instead?
Additional information
and resolv.conf doesn't exist. All other test cases that use localhost are passing, as expected.
The text was updated successfully, but these errors were encountered: