Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IO-Socket-IP test increases running time of test suite #13541

Closed
p5pRT opened this issue Jan 19, 2014 · 19 comments
Closed

IO-Socket-IP test increases running time of test suite #13541

p5pRT opened this issue Jan 19, 2014 · 19 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Jan 19, 2014

Migrated from rt.perl.org#121037 (status was 'resolved')

Searchable as RT121037$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 19, 2014

From @jkeenan

I test blead on the dromedary server several times a week with​:

TEST_JOBS=8 make -j8 test_harness

Though I don't transcribe each test run, I have a sense of which tests
are going to be the last to run. Tonight, I noticed that the test suite
seemed to be hanging at the very end of the suite due to the addition of
new, very long running test files.

#####
../lib/perl5db.t .................................................. ok
../lib/locale.t ................................................... ok
../cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t ........... ok
../cpan/IO-Socket-IP/t/99pod.t ....................................
skipped​: Test​::Pod 1.00 required for testing POD
All tests successful.
Files=2392, Tests=685227, 176 wallclock secs (71.59 usr 8.27 sys +
434.09 cusr 39.77 csys = 553.72 CPU)
Result​: PASS
#####

There was a noticeably long hang while
cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t ran. I then
individually ran and timed the last two files in the output above​:

#####
[dromedary-001​:perl] 1003 $ cd t; time ./perl harness -v
../cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t; cd -

ok 1 # skip Can't connect to cpanidx.org​:80
ok 2 # skip Can't connect to cpanidx.org​:80
ok 3 # skip Can't connect to cpanidx.org​:80
ok 4 # skip Can't connect to cpanidx.org​:80
ok 5 # skip Can't connect to cpanidx.org​:80
ok 6 # skip Connecting to cpanidx.org​:6666 doesn't give ECONNREFUSED
ok 7 # skip Connecting to cpanidx.org​:6666 doesn't give ECONNREFUSED
ok 8 # skip Connecting to cpanidx.org​:6666 doesn't give ECONNREFUSED
ok 9 # skip Connecting to cpanidx.org​:6666 doesn't give ECONNREFUSED
ok
All tests successful.
Files=1, Tests=9, 126 wallclock secs ( 0.01 usr 0.00 sys + 0.04 cusr
0.00 csys = 0.05 CPU)
Result​: PASS

real 2m6.120s
user 0m0.117s
sys 0m0.008s
/home/jkeenan/perl

[dromedary-001​:perl] 1004 $ cd t; time ./perl harness -v
../cpan/IO-Socket-IP/t/99pod.t; cd -
skipped​: Test​::Pod 1.00 required for testing POD
Files=1, Tests=0, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.01 cusr
0.00 csys = 0.02 CPU)
Result​: NOTESTS

real 0m0.088s
user 0m0.075s
sys 0m0.017s
/home/jkeenan/perl
#####

These files appear to have come into the core test suite today with​:

#####
commit e150c45
Author​: Ricardo Signes <rjbs@​cpan.org>
Date​: Sun Jan 19 09​:33​:13 2014 -0500

  tentatively import IO-Socket-IP for consideration
#####

Problems​:

I.

With a running time of 2m6.120s on dromedary,
cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t almost certainly
becomes the longest running test in the entire Perl 5 suite. Based on
past experience, if this file takes more than two minutes on the
super-fast dromedary machine, it will take more than 5 minutes on many
machines which test blead and over 10 on others. This will inhibit
quick turnaround of patches and bug fixes in core.

Can anything be done about this file's running time?

II.

Since Test​::Pod is not distributed with core (<aside>A good thing,
IMO</aside>), the tests in cpan/IO-Socket-IP/t/99pod.t will never be
run. This file should not be part of the core distro, only the on-CPAN
distro.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 19, 2014

From @jkeenan

Summary of my perl5 (revision 5 version 12 subversion 3) configuration​:
  Commit id​: c024706
  Platform​:
  osname=linux, osvers=2.6.18-164.6.1.el5, archname=x86_64-linux-ld
  uname='linux dromedary 2.6.18-164.6.1.el5 #1 smp tue nov 3 16​:12​:36 est 2009 x86_64 x86_64 x86_64 gnulinux '
  config_args='-DDEBUGGING -Uusethreads -Duse64bitint'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-50)', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8
  alignbytes=16, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
  libs=-lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.5'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:
  Compile-time options​: DEBUGGING PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
  USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES
  USE_LONG_DOUBLE USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at May 11 2011 22​:43​:27
  %ENV​:
  PERLBREW_BASHRC_VERSION="0.63"
  PERLBREW_HOME="/home/jkeenan/.perlbrew"
  PERLBREW_ROOT="/home/jkeenan/perl5/perlbrew"
  @​INC​:
  /usr/local/lib/perl5/site_perl/5.12.3/x86_64-linux-ld
  /usr/local/lib/perl5/site_perl/5.12.3
  /usr/local/lib/perl5/5.12.3/x86_64-linux-ld
  /usr/local/lib/perl5/5.12.3
  .

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 19, 2014

From @leonerd

On Sun, 19 Jan 2014 15​:28​:14 -0800
James E Keenan (via RT) <perlbug-followup@​perl.org> wrote​:

With a running time of 2m6.120s on dromedary,
cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t almost certainly
becomes the longest running test in the entire Perl 5 suite. Based
on past experience, if this file takes more than two minutes on the
super-fast dromedary machine, it will take more than 5 minutes on
many machines which test blead and over 10 on others. This will
inhibit quick turnaround of patches and bug fixes in core.

It's quick when I run it​:

  $ time prove -b t/31nonblocking-connect-internet.t
  t/31nonblocking-connect-internet.t .. ok
  All tests successful.
  Files=1, Tests=9, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr
  0.01 csys = 0.08 CPU) Result​: PASS

  real 0m0.318s
  user 0m0.164s
  sys 0m0.020s

I don't think this is CPU-spinning time. That 2 minutes is probably TCP
timeout failures, so should be independent of CPU time.

That said, it still shouldn't take 2 minutes to fail. Maybe some odd
networking setup on the box you're testing with?

Since Test​::Pod is not distributed with core (<aside>A good thing,
IMO</aside>), the tests in cpan/IO-Socket-IP/t/99pod.t will never be
run. This file should not be part of the core distro, only the
on-CPAN distro.

Ahyes - should just kill the t/99pod.t file for a core import.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http​://www.leonerd.org.uk/

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 19, 2014

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 19, 2014

From @craigberry

On Sun, Jan 19, 2014 at 5​:28 PM, James E Keenan
<perlbug-followup@​perl.org> wrote​:

With a running time of 2m6.120s on dromedary,
cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t almost certainly
becomes the longest running test in the entire Perl 5 suite. Based on
past experience, if this file takes more than two minutes on the
super-fast dromedary machine, it will take more than 5 minutes on many
machines which test blead and over 10 on others. This will inhibit
quick turnaround of patches and bug fixes in core.

Can anything be done about this file's running time?

On my 10-year-old OpenVMS I64 box (which normally takes about 2 hours
to run the test suite) it takes​:

$ pipe show time ; perl t/31nonblocking-connect-internet.t ; show time
  19-JAN-2014 17​:38​:07
ok 1 - defined $socket for cpanidx.org​:80
ok 2 - $socket has fileno
ok 3 - $socket not yet connected
ok 4 - ->connect eventually succeeds
ok 5 - $socket now connected
ok 6 - defined $socket for cpanidx.org​:6666
ok 7 - $socket has fileno
ok 8 - $socket not yet connected
ok 9 - ->connect eventually fails with ECONNREFUSED
1..9
  19-JAN-2014 17​:38​:09

two seconds. Without having looked at the code, given the word
"internet" in the test name and the fact that it skips everything due
to connection failures, it seems likely there is something involving
what outbound connections are allowed from dromedary.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From @jkeenan

On Sun Jan 19 15​:40​:32 2014, leonerd@​leonerd.org.uk wrote​:

On Sun, 19 Jan 2014 15​:28​:14 -0800
James E Keenan (via RT) <perlbug-followup@​perl.org> wrote​:

With a running time of 2m6.120s on dromedary,
cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t almost certainly
becomes the longest running test in the entire Perl 5 suite. Based
on past experience, if this file takes more than two minutes on the
super-fast dromedary machine, it will take more than 5 minutes on
many machines which test blead and over 10 on others. This will
inhibit quick turnaround of patches and bug fixes in core.

It's quick when I run it​:

$ time prove -b t/31nonblocking-connect-internet.t
t/31nonblocking-connect-internet.t .. ok
All tests successful.
Files=1, Tests=9, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr
0.01 csys = 0.08 CPU) Result​: PASS

real 0m0.318s
user 0m0.164s
sys 0m0.020s

I don't think this is CPU-spinning time. That 2 minutes is probably TCP
timeout failures, so should be independent of CPU time.

That said, it still shouldn't take 2 minutes to fail. Maybe some odd
networking setup on the box you're testing with?

Perhaps. But this is the main Perl 5 development server, donated by booking.com and maintained by Seveas. So if it has an "odd networking setup", it's probably for a good reason beyond my non-sysadmin's understanding.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From @jkeenan

On Sun Jan 19 15​:43​:53 2014, craig.a.berry@​gmail.com wrote​:

On Sun, Jan 19, 2014 at 5​:28 PM, James E Keenan
<perlbug-followup@​perl.org> wrote​:

With a running time of 2m6.120s on dromedary,
cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t almost certainly
becomes the longest running test in the entire Perl 5 suite. Based on
past experience, if this file takes more than two minutes on the
super-fast dromedary machine, it will take more than 5 minutes on many
machines which test blead and over 10 on others. This will inhibit
quick turnaround of patches and bug fixes in core.

Can anything be done about this file's running time?

On my 10-year-old OpenVMS I64 box (which normally takes about 2 hours
to run the test suite) it takes​:

$ pipe show time ; perl t/31nonblocking-connect-internet.t ; show time
19-JAN-2014 17​:38​:07
ok 1 - defined $socket for cpanidx.org​:80
ok 2 - $socket has fileno
ok 3 - $socket not yet connected
ok 4 - ->connect eventually succeeds
ok 5 - $socket now connected
ok 6 - defined $socket for cpanidx.org​:6666
ok 7 - $socket has fileno
ok 8 - $socket not yet connected
ok 9 - ->connect eventually fails with ECONNREFUSED
1..9
19-JAN-2014 17​:38​:09

two seconds. Without having looked at the code, given the word
"internet" in the test name and the fact that it skips everything due
to connection failures, it seems likely there is something involving
what outbound connections are allowed from dromedary.

Thanks for that analysis. Are there any other situations in the test suite where a library, for its own sanity-checking, needs to test outbound connections? If so, then we may have some prior art with respect to getting this test file to do the right thing.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From perl5-porters@perl.org

James Keenan wrote​:

Perhaps. But this is the main Perl 5 development server, donated by
booking.com and maintained by Seveas. So if it has an "odd networking
setup", it's probably for a good reason beyond my non-sysadmin's
understanding.

The first rule of portable testing should be not to assume there are
*any* networking capabilities.

The solution in this case is usually to set the timeout to a few sec-
onds. (Any more than 5 seconds is annoying. I prefer something
shorter like 2 or 3.)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From perl5-porters@perl.org

I wrote​:

The solution in this case is usually to set the timeout to a few sec-
onds. (Any more than 5 seconds is annoying. I prefer something
shorter like 2 or 3.)

Since the test ignores $ENV{PROXY}, it does this on my develope-
ment machine​:

$ time ./perl -Ilib cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
ok 1 # skip Can't connect to cpanidx.org​:80
ok 2 # skip Can't connect to cpanidx.org​:80
ok 3 # skip Can't connect to cpanidx.org​:80
ok 4 # skip Can't connect to cpanidx.org​:80
ok 5 # skip Can't connect to cpanidx.org​:80
ok 6 - defined $socket for cpanidx.org​:6666
ok 7 - $socket has fileno
ok 8 - $socket not yet connected
ok 9 - ->connect eventually fails with ECONNREFUSED
1..9

real 1m20.383s
user 0m0.166s
sys 0m0.013s

This makes it tolerable​:

Inline Patch
diff --git a/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t b/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
index b236205..8dc3ca0 100644
--- a/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
+++ b/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
@@ -20,6 +20,7 @@ SKIP: {
       PeerHost => $test_host,
       PeerPort => $test_good_port,
       Type     => SOCK_STREAM,
+      Timeout  => 3,
    ) or skip "Can't connect to $test_host:$test_good_port", 5;
 
    my $socket = IO::Socket::IP->new(
@@ -57,6 +58,7 @@ SKIP: {
       PeerHost => $test_host,
       PeerPort => $test_bad_port,
       Type     => SOCK_STREAM,
+      Timeout  => 3,
    ) and skip "Connecting to $test_host:$test_bad_port succeeds", 4;
    $! == ECONNREFUSED or skip "Connecting to $test_host:$test_bad_port doesn't give ECONNREFUSED", 4;
 

The result:

real 0m7.736s
user 0m0.171s
sys 0m0.012s

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From @jkeenan

On Sun Jan 19 17​:28​:18 2014, perl5-porters@​perl.org wrote​:

I wrote​:

The solution in this case is usually to set the timeout to a few sec-
onds. (Any more than 5 seconds is annoying. I prefer something
shorter like 2 or 3.)

Since the test ignores $ENV{PROXY}, it does this on my develope-
ment machine​:

$ time ./perl -Ilib cpan/IO-Socket-IP/t/31nonblocking-connect-
internet.t
ok 1 # skip Can't connect to cpanidx.org​:80
ok 2 # skip Can't connect to cpanidx.org​:80
ok 3 # skip Can't connect to cpanidx.org​:80
ok 4 # skip Can't connect to cpanidx.org​:80
ok 5 # skip Can't connect to cpanidx.org​:80
ok 6 - defined $socket for cpanidx.org​:6666
ok 7 - $socket has fileno
ok 8 - $socket not yet connected
ok 9 - ->connect eventually fails with ECONNREFUSED
1..9

real 1m20.383s
user 0m0.166s
sys 0m0.013s

This makes it tolerable​:

diff --git a/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
b/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
index b236205..8dc3ca0 100644
--- a/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
+++ b/cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t
@​@​ -20,6 +20,7 @​@​ SKIP​: {
PeerHost => $test_host,
PeerPort => $test_good_port,
Type => SOCK_STREAM,
+ Timeout => 3,
) or skip "Can't connect to $test_host​:$test_good_port", 5;

my $socket = IO​::Socket​::IP->new(
@​@​ -57,6 +58,7 @​@​ SKIP​: {
PeerHost => $test_host,
PeerPort => $test_bad_port,
Type => SOCK_STREAM,
+ Timeout => 3,
) and skip "Connecting to $test_host​:$test_bad_port succeeds", 4;
$! == ECONNREFUSED or skip "Connecting to $test_host​:$test_bad_port
doesn't give ECONNREFUSED", 4;

The result​:

real 0m7.736s
user 0m0.171s
sys 0m0.012s

+1

I confirmed that if network connections are available, the test runs quickly. On my slowest machine​:

#####
$ cd t; time ./perl harness -v ../cpan/IO-Socket-IP/t/31nonblocking-connect-internet.t; cd -

ok 1 - defined $socket for cpanidx.org​:80
ok 2 - $socket has fileno
ok 3 - $socket not yet connected
ok 4 - ->connect eventually succeeds
ok 5 - $socket now connected
ok 6 - defined $socket for cpanidx.org​:6666
ok 7 - $socket has fileno
ok 8 - $socket not yet connected
ok 9 - ->connect eventually fails with ECONNREFUSED
ok
All tests successful.
Files=1, Tests=9, 2 wallclock secs ( 0.05 usr 0.02 sys + 0.25 cusr 0.07 csys = 0.39 CPU)
Result​: PASS

real 0m4.567s
user 0m0.654s
sys 0m0.230s
/Users/jimk/gitwork/perl
#####

rjbs or LeoNerd or whoever is shepherding this library into core​: Can you apply Father C's patch (or its moral equivalant)?

That will leave only the POD test issue to be dealt with.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From @wolfsage

On Sun, Jan 19, 2014 at 9​:30 PM, James E Keenan via RT
<perlbug-followup@​perl.org> wrote​:

That will leave only the POD test issue to be dealt with.

What about these?

  ../cpan/Archive-Tar/t/99_pod.t ....................................
skipped​: Test​::Pod v0.95 required for testing POD
  ../cpan/Config-Perl-V/t/00_pod.t ..................................
skipped​: Test​::Pod 1.00 required for testing POD
  ../cpan/Config-Perl-V/t/01_pod.t ..................................
skipped​: Test​::Pod​::Covarage required for testing POD Coverage
  ../cpan/Compress-Raw-Bzip2/t/99pod.t ..............................
skipped​: Test​::Pod 1.00 required for testing POD
  ../cpan/IPC-SysV/t/pod.t ..........................................
skipped​: testing pod requires Test​::Pod
  ../cpan/podlators/t/pod.t .........................................
skipped​: Test​::Pod 1.00 required for testing POD
  ../dist/Module-CoreList/t/pod.t ...................................
skipped​: Test​::Pod 1.00 required for testing POD
  ../cpan/IO-Compress/t/999pod.t ....................................
skipped​: Test​::Pod 1.00 required for testing POD

-- Matthew Horsfall (alh)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From @leonerd

On Sun, 19 Jan 2014 18​:30​:17 -0800
"James E Keenan via RT" <perlbug-followup@​perl.org> wrote​:

rjbs or LeoNerd or whoever is shepherding this library into core​:
Can you apply Father C's patch (or its moral equivalant)?

That's now in my upstream source, to go in the next CPAN release.

I'm loathe to make a new release just for this change though, so I'll
see what else comes in. But happy to suggest just applying the same
change to the copy in perl core.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http​://www.leonerd.org.uk/

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From dennis@kaarsemaker.net

On zo, 2014-01-19 at 16​:13 -0800, James E Keenan via RT wrote​:

That said, it still shouldn't take 2 minutes to fail. Maybe some odd
networking setup on the box you're testing with?

Perhaps. But this is the main Perl 5 development server, donated by
booking.com and maintained by Seveas. So if it has an "odd networking
setup", it's probably for a good reason beyond my non-sysadmin's
understanding.

The only thing odd is that it doesn't have direct internet access.
Though the firewall simply drops the packets instead of rejecting them,
rejecting might make the test fail faster.

--
Dennis Kaarsemaker
www.kaarsemaker.net

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Jan 20, 2014

From @leonerd

On Mon, 20 Jan 2014 22​:43​:39 +0100
Dennis Kaarsemaker <dennis@​kaarsemaker.net> wrote​:

The only thing odd is that it doesn't have direct internet access.
Though the firewall simply drops the packets instead of rejecting
them, rejecting might make the test fail faster.

Oh. Then this is definitely the problem.

If packets simply get dropped, connect() has no way to know this is
happening. It'll retry a few times, eventually timing out after (I
believe a default of) 30 seconds. There's 4 connect() tests in the
file, thus leading to this 2 minute delay.

Rejecting instead of silently blackholing would definitely make this
test faster, and likely others too.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http​://www.leonerd.org.uk/

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 18, 2014

From @jkeenan

On Mon Jan 20 14​:32​:55 2014, leonerd@​leonerd.org.uk wrote​:

On Mon, 20 Jan 2014 22​:43​:39 +0100
Dennis Kaarsemaker <dennis@​kaarsemaker.net> wrote​:

The only thing odd is that it doesn't have direct internet access.
Though the firewall simply drops the packets instead of rejecting
them, rejecting might make the test fail faster.

Oh. Then this is definitely the problem.

If packets simply get dropped, connect() has no way to know this is
happening. It'll retry a few times, eventually timing out after (I
believe a default of) 30 seconds. There's 4 connect() tests in the
file, thus leading to this 2 minute delay.

Rejecting instead of silently blackholing would definitely make this
test faster, and likely others too.

Paul, would it be possible to get an update on the status of this ticket?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 20, 2014

From @leonerd

On Sun, 18 May 2014 07​:28​:44 -0700
"James E Keenan via RT" <perlbug-followup@​perl.org> wrote​:

On Mon Jan 20 14​:32​:55 2014, leonerd@​leonerd.org.uk wrote​:

On Mon, 20 Jan 2014 22​:43​:39 +0100
Dennis Kaarsemaker <dennis@​kaarsemaker.net> wrote​:

The only thing odd is that it doesn't have direct internet access.
Though the firewall simply drops the packets instead of rejecting
them, rejecting might make the test fail faster.

Oh. Then this is definitely the problem.

If packets simply get dropped, connect() has no way to know this is
happening. It'll retry a few times, eventually timing out after (I
believe a default of) 30 seconds. There's 4 connect() tests in the
file, thus leading to this 2 minute delay.

Rejecting instead of silently blackholing would definitely make this
test faster, and likely others too.

Paul, would it be possible to get an update on the status of this
ticket?

Uhwhat? I wasn't aware that /I/ had to do anything with it.

The fault is with the firewall, silently dropping packets as if a wire
was broken, instead of properly rejecting them with ICMP unreach
messages. There's basically nothing I can do about that.

--
Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk
http​://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS

@p5pRT
Copy link
Author

@p5pRT p5pRT commented May 20, 2014

From dennis@kaarsemaker.net

On di, 2014-05-20 at 15​:14 +0100, Paul "LeoNerd" Evans wrote​:

On Sun, 18 May 2014 07​:28​:44 -0700
"James E Keenan via RT" <perlbug-followup@​perl.org> wrote​:

On Mon Jan 20 14​:32​:55 2014, leonerd@​leonerd.org.uk wrote​:

On Mon, 20 Jan 2014 22​:43​:39 +0100
Dennis Kaarsemaker <dennis@​kaarsemaker.net> wrote​:

The only thing odd is that it doesn't have direct internet access.
Though the firewall simply drops the packets instead of rejecting
them, rejecting might make the test fail faster.

Oh. Then this is definitely the problem.

If packets simply get dropped, connect() has no way to know this is
happening. It'll retry a few times, eventually timing out after (I
believe a default of) 30 seconds. There's 4 connect() tests in the
file, thus leading to this 2 minute delay.

Rejecting instead of silently blackholing would definitely make this
test faster, and likely others too.

Paul, would it be possible to get an update on the status of this
ticket?

Uhwhat? I wasn't aware that /I/ had to do anything with it.

The fault is with the firewall, silently dropping packets as if a wire
was broken, instead of properly rejecting them with ICMP unreach
messages. There's basically nothing I can do about that.

Agreed, the tests are doing what they should do. I've now added a rule
to the firewall to reject unwhitelisted traffic to the outside instead
of dropping it.

--
Dennis Kaarsemaker
www.kaarsemaker.net

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 17, 2014

From @jkeenan

On Tue May 20 07​:44​:54 2014, dennis@​kaarsemaker.net wrote​:

On di, 2014-05-20 at 15​:14 +0100, Paul "LeoNerd" Evans wrote​:

On Sun, 18 May 2014 07​:28​:44 -0700
"James E Keenan via RT" <perlbug-followup@​perl.org> wrote​:

On Mon Jan 20 14​:32​:55 2014, leonerd@​leonerd.org.uk wrote​:

On Mon, 20 Jan 2014 22​:43​:39 +0100
Dennis Kaarsemaker <dennis@​kaarsemaker.net> wrote​:

The only thing odd is that it doesn't have direct internet access.
Though the firewall simply drops the packets instead of rejecting
them, rejecting might make the test fail faster.

Oh. Then this is definitely the problem.

If packets simply get dropped, connect() has no way to know this is
happening. It'll retry a few times, eventually timing out after (I
believe a default of) 30 seconds. There's 4 connect() tests in the
file, thus leading to this 2 minute delay.

Rejecting instead of silently blackholing would definitely make this
test faster, and likely others too.

Paul, would it be possible to get an update on the status of this
ticket?

Uhwhat? I wasn't aware that /I/ had to do anything with it.

The fault is with the firewall, silently dropping packets as if a wire
was broken, instead of properly rejecting them with ICMP unreach
messages. There's basically nothing I can do about that.

Agreed, the tests are doing what they should do. I've now added a rule
to the firewall to reject unwhitelisted traffic to the outside instead
of dropping it.

There has been no correspondence in this ticket since May. It appears the test suite is taking a normal amount of time to complete. So I'm marking this ticket Resolved.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 17, 2014

@jkeenan - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this Oct 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant