bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Philipp]

This is another follow-up to bug#30700, this time about the test
echo-server-with-dns.

Test echo-server-with-dns backtrace:
  make-network-process(:name "server" :server t :noquery t :family ipv
  make-server("p")
  #f(compiled-function () #<bytecode 0x19bcc38041173061>)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name echo-server-with-dns :documentation n
  ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [... 
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/network-stream-t
  command-line()
  normal-top-level()
Test echo-server-with-dns condition:
    (error "p/0 nodename nor servname provided, or not known")
   FAILED   8/27  echo-server-with-dns (0.006517 sec)

In this case, this might be an issue with the macOS firewall: 'make
check' results in a few prompts whether incoming connections should be
accepted, and I've declined these prompts.


In GNU Emacs 28.0.50 (build 67, x86_64-apple-darwin19.5.0, NS appkit-1894.50 Version 10.15.5 (Build 19F101))
 of 2020-07-25
Repository revision: 3b44829823f43d3736b8ec9db2258eeff7f6c16a
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.5

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
JPEG TIFF GIF PNG NOTIFY KQUEUE ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS
MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822
mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils phst skeleton derived edmacro
kmacro pcase ffap thingatpt url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars mailcap subr-x rx gnutls puny seq
byte-opt gv bytecomp byte-compile cconv dbus xml compile comint
ansi-color ring cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 69704 6782)
 (symbols 48 8650 1)
 (strings 32 23539 1292)
 (string-bytes 1 768345)
 (vectors 16 14143)
 (vector-slots 8 172492 7594)
 (floats 8 26 29)
 (intervals 56 207 0)
 (buffers 992 10))

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Robert Pluim]

>>>>> On Sat, 25 Jul 2020 20:39:37 +0200, Philipp <p.stephani2@gmail.com> said:

    Philipp> This is another follow-up to bug#30700, this time about the test
    Philipp> echo-server-with-dns.

    Philipp> Test echo-server-with-dns backtrace:
    Philipp>   make-network-process(:name "server" :server t :noquery t :family ipv
    Philipp>   make-server("p")
    Philipp>   #f(compiled-function () #<bytecode 0x19bcc38041173061>)()
    Philipp>   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
    Philipp>   ert-run-test(#s(ert-test :name echo-server-with-dns :documentation n
    Philipp>   ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [... 
    Philipp>   ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
    Philipp>   ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
    Philipp>   ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
    Philipp>   eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
    Philipp>   command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/net/network-stream-t
    Philipp>   command-line()
    Philipp>   normal-top-level()
    Philipp> Test echo-server-with-dns condition:
    Philipp>     (error "p/0 nodename nor servname provided, or not known")
    Philipp>    FAILED   8/27  echo-server-with-dns (0.006517 sec)

    Philipp> In this case, this might be an issue with the macOS firewall: 'make
    Philipp> check' results in a few prompts whether incoming connections should be
    Philipp> accepted, and I've declined these prompts.

The test also assumes that (system-name) results in a resolvable name,
which is not always true (you can stick an entry in /etc/hosts to make
it true).

Robert

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> The test also assumes that (system-name) results in a resolvable name,
> which is not always true (you can stick an entry in /etc/hosts to make
> it true).

It's supposed to test DNS, though -- is there something that'll be more
reliable than (system-name)?  (Not that it's reliable, but...  more.  :-))

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Philipp <p.stephani2@gmail.com> writes:

> This is another follow-up to bug#30700, this time about the test
> echo-server-with-dns.

[...]

> In this case, this might be an issue with the macOS firewall: 'make
> check' results in a few prompts whether incoming connections should be
> accepted, and I've declined these prompts.

Is that something we can test for, though?  If you've set up your
machine to not accept network connections from itself, then you'd think
all of the network tests would fail (and should be skipped).

But is there a way to test for that?

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Robert Pluim]

>>>>> On Tue, 04 Aug 2020 16:12:03 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> The test also assumes that (system-name) results in a resolvable name,
    >> which is not always true (you can stick an entry in /etc/hosts to make
    >> it true).

    Lars> It's supposed to test DNS, though -- is there something that'll be more
    Lars> reliable than (system-name)?  (Not that it's reliable, but...  more.  :-))

localhost? But the next test already checks that. Is anyone still
running any public echo servers?

If what you really want to test is "does DNS work", then
src/process-tests.el already does that with 'network-lookup-address-info',
which shares the actual lookup code with 'make-network-process'.

Robert

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> localhost? But the next test already checks that. Is anyone still
> running any public echo servers?

Isn't localhost hard-coded to 127.0.0.1/::1 and doesn't use the resolver
at all?

> If what you really want to test is "does DNS work", then
> src/process-tests.el already does that with 'network-lookup-address-info',
> which shares the actual lookup code with 'make-network-process'.

No, I think that code really wants to check whether we can make a
network process work with DNS, because that's a different code path than
just network-lookup-address-info + make-network-process.

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Robert Pluim]

>>>>> On Tue, 04 Aug 2020 16:39:02 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> localhost? But the next test already checks that. Is anyone still
    >> running any public echo servers?

    Lars> Isn't localhost hard-coded to 127.0.0.1/::1 and doesn't use the resolver
    Lars> at all?

Yes.

    >> If what you really want to test is "does DNS work", then
    >> src/process-tests.el already does that with 'network-lookup-address-info',
    >> which shares the actual lookup code with 'make-network-process'.

    Lars> No, I think that code really wants to check whether we can make a
    Lars> network process work with DNS, because that's a different code path than
    Lars> just network-lookup-address-info + make-network-process.

Then either we need to accept that this test can fail on some systems,
or we risk calling the wrath of <insert large internet company> down upon us by
putting one of their public servers in the test. Or we just use www.gnu.org

Robert

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Then either we need to accept that this test can fail on some systems,
> or we risk calling the wrath of <insert large internet company> down
> upon us by putting one of their public servers in the test. Or we just
> use www.gnu.org

We can't use anything external -- that'd fail a lot more than using
(system-name).

But we should just disable this test if (system-name) doesn't resolve.
That should be easy enough to check for.  

(network-lookup-address-info (system-name))
=> ([127 0 1 1 0])

So reasonable values here would be 127 as the first octet on ipv4...

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Robert Pluim]

>>>>> On Tue, 04 Aug 2020 17:02:14 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Then either we need to accept that this test can fail on some systems,
    >> or we risk calling the wrath of <insert large internet company> down
    >> upon us by putting one of their public servers in the test. Or we just
    >> use www.gnu.org

    Lars> We can't use anything external -- that'd fail a lot more than using
    Lars> (system-name).

    Lars> But we should just disable this test if (system-name) doesn't resolve.
    Lars> That should be easy enough to check for.  

    Lars> (network-lookup-address-info (system-name))
    Lars> => ([127 0 1 1 0])

    Lars> So reasonable values here would be 127 as the first octet on ipv4...

Why restrict yourself to IPv4?

(network-lookup-address-info (system-name))
=> ([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])

Note that strictly speaking this doesnʼt test DNS, since in my case
itʼs just looking in /etc/hosts, but it does test the resolver.

Robert

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Why restrict yourself to IPv4?
>
> (network-lookup-address-info (system-name))
> => ([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])

Sure.  So if the first octet is 0 or 127, then we have a resolving
(system-name)?  I'm not sure what the rules are on ipv6 for localhost...

> Note that strictly speaking this doesnʼt test DNS, since in my case
> itʼs just looking in /etc/hosts, but it does test the resolver.

Yes, but from make-network-process's point of view, that doesn't make
any difference, I think...

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Andreas Schwab]

On Aug 04 2020, Lars Ingebrigtsen wrote:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> Why restrict yourself to IPv4?
>>
>> (network-lookup-address-info (system-name))
>> => ([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])
>
> Sure.  So if the first octet is 0 or 127, then we have a resolving
> (system-name)?

(system-name) can also resolve to a real IP.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Sure.  So if the first octet is 0 or 127, then we have a resolving
>> (system-name)?
>
> (system-name) can also resolve to a real IP.

Yeah, but we don't really need to run this test on all machines in the
world...  that it's disabled for a number is better than it fails for a
different subset.

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Philipp <p.stephani2@gmail.com> writes:

> This is another follow-up to bug#30700, this time about the test
> echo-server-with-dns.
>
> Test echo-server-with-dns backtrace:
>   make-network-process(:name "server" :server t :noquery t :family ipv

I've now disabled this test if it looks like (system-name) isn't
localhost on the machine.  Can you try this and see whether it fixes
this test case on your machine?  (The test doesn't fail on my Apple
laptop.)

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Robert Pluim]

>>>>> On Tue, 04 Aug 2020 17:16:02 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Why restrict yourself to IPv4?
    >> 
    >> (network-lookup-address-info (system-name))
    >> => ([0 0 0 0 0 0 0 1 0] [127 0 0 1 0])

    Lars> Sure.  So if the first octet is 0 or 127, then we have a resolving
    Lars> (system-name)?  I'm not sure what the rules are on ipv6 for localhost...

There is one and only one IPv6 localhost, and itʼs the one
above. There are no currently assigned IPv6 prefixes with a 0 in the
first octet, but in 40 years, who know?

IPv4 localhost is anything in 127.0.0.0/8, so testing the first octet
is enough.

Robert

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Robert Pluim]

>>>>> On Tue, 04 Aug 2020 17:26:54 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Andreas Schwab <schwab@linux-m68k.org> writes:
    >>> Sure.  So if the first octet is 0 or 127, then we have a resolving
    >>> (system-name)?
    >> 
    >> (system-name) can also resolve to a real IP.

    Lars> Yeah, but we don't really need to run this test on all machines in the
    Lars> world...  that it's disabled for a number is better than it fails for a
    Lars> different subset.

'network-lookup-address-info' returns nil if it canʼt resolve the
hostname, and if it happens to return a non-loopback IP, what's wrong
with trying to connect to it? It will be local anyway.

Robert

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Philipp Stephani]

Am Di., 4. Aug. 2020 um 17:28 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
> Philipp <p.stephani2@gmail.com> writes:
>
> > This is another follow-up to bug#30700, this time about the test
> > echo-server-with-dns.
> >
> > Test echo-server-with-dns backtrace:
> >   make-network-process(:name "server" :server t :noquery t :family ipv
>
> I've now disabled this test if it looks like (system-name) isn't
> localhost on the machine.  Can you try this and see whether it fixes
> this test case on your machine?  (The test doesn't fail on my Apple
> laptop.)

Yes, the test is now being skipped on my machine. Thanks.

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Philipp Stephani <p.stephani2@gmail.com> writes:

> Yes, the test is now being skipped on my machine. Thanks.

Thanks for testing; closing the bug report.

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> 'network-lookup-address-info' returns nil if it canʼt resolve the
> hostname, and if it happens to return a non-loopback IP, what's wrong
> with trying to connect to it? It will be local anyway.

It's just one more thing that may fail -- somebody may have set
(system-name) to something that does resolve, but isn't the local
machine.  People do all kinds of odd things.

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

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Robert Pluim]

>>>>> On Tue, 04 Aug 2020 18:12:51 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> 'network-lookup-address-info' returns nil if it canʼt resolve the
    >> hostname, and if it happens to return a non-loopback IP, what's wrong
    >> with trying to connect to it? It will be local anyway.

    Lars> It's just one more thing that may fail -- somebody may have set
    Lars> (system-name) to something that does resolve, but isn't the local
    Lars> machine.  People do all kinds of odd things.

Well, you could always check against 'network-interface-list', but
thatʼs probably overkill.

Robert

bug#42535: 28.0.50; macOS test failure: echo-server-with-dns

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Tue, 04 Aug 2020 17:25:42 +0200
> Cc: 42535@debbugs.gnu.org, Robert Pluim <rpluim@gmail.com>,
>  Philipp <p.stephani2@gmail.com>
> 
> (system-name) can also resolve to a real IP.

Indeed, it does here.