Public bug reported:
$ autopkgtest-buildvm-ubuntu-cloud --arch i386
put system under load; e.g. pull-lp-source boost1.67; cd boost1.67;
DEB_BUILD_OPTIONS=parallel=12 ./debian/rules build should do it, on an
4core/8hypercore system
$ autopkgtest -s --shell --apt-pocket=proposed --apt-upgrade python3.6
--test-name testsuite -- qemu -c 1 -q qemu-system-i386 ./autopkgtest-
cosmic-i386.img
test_ssl fails
To rerun test_ssl alone, one can do:
$ python3.6 -W default -bb -E -R -m test -j 1 -w -uall,-network,-urlfetch,-gui
test_ssl --verbose
in a racy manner, for many test cases, due to ConnectionRefused from the
TestEchoServer
One way to solve this is to reduce the load, cause without load
TestEchoServer keeps up just fine.
Symptoms are s.connect failing with ConnectionRefusedError, or for
example s.getpeercreds failing with Transport not connected.
I'm not sure it's worth any time fixing this test-server implementation,
as clearly it is testing the ssl server/client bits, that work correctly
on a normal, not-under-stress systems. And thus the ssl bits are
correctly validated.
I will try to create a reproducer which does not involve VMs and
stressing host.
meanwhile it would be nice to run python tests on slightly bigger
machines, e.g. mark it as big_packages.
** Affects: auto-package-testing
Importance: Undecided
Status: New
** Affects: python3.6 (Ubuntu)
Importance: Undecided
Status: New
** Also affects: auto-package-testing
Importance: Undecided
Status: New
** Description changed:
$ autopkgtest-buildvm-ubuntu-cloud --arch i386
put system under load; e.g. pull-lp-source boost1.67; cd boost1.67;
DEB_BUILD_OPTIONS=parallel=12 ./debian/rules build should do it, on an
4core/8hypercore system
$ autopkgtest -s --shell --apt-pocket=proposed --apt-upgrade python3.6
--test-name testsuite -- qemu -c 1 -q qemu-system-i386 ./autopkgtest-
cosmic-i386.img
test_ssl fails
in a racy manner, for many test cases, due to ConnectionRefused from the
TestEchoServer
One way to solve this is to reduce the load, cause without load
TestEchoServer keeps up just fine.
Symptoms are s.connect failing with ConnectionRefusedError, or for
example s.getpeercreds failing with Transport not connected.
I'm not sure it's worth any time fixing this test-server implementation,
as clearly it is testing the ssl server/client bits, that work correctly
on a normal, not-under-stress systems. And thus the ssl bits are
correctly validated.
I will try to create a reproducer which does not involve VMs and
stressing host.
+
+ meanwhile it would be nice to run python tests on slightly bigger
+ machines, e.g. mark it as big_packages.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1795999
Title:
python3.6 test_ssl fails reliably on systems under load
To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/1795999/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
