The mystery continues. On 04-04-2024 10:08 p.m., Paul Gevers wrote:
I forgot that on amd64, autopkgtest's autopkgtest now runs in qemu which doesn't benefit yet as much from tmpfs as lxc does, so it's not a good comparison.
On ci-worker13: """ root@elbrus:/tmp/autopkgtest-lxc.ww6f2cls/downtmp/build.VWV/src# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 250G 44G 207G 18% / none 492K 4.0K 488K 1% /dev tmpfs 126G 0 126G 0% /dev/shm tmpfs 51G 52K 51G 1% /run tmpfs 5.0M 0 5.0M 0% /run/lockroot@elbrus:/tmp/autopkgtest-lxc.ww6f2cls/downtmp/build.VWV/src# AUTOPKGTEST_TEST_SCHROOT=testing-amd64-sbuild tests/autopkgtest SchrootRunner.test_copy_timeout
test_copy_timeout (__main__.SchrootRunner.test_copy_timeout) handling copying timeout ... ok ---------------------------------------------------------------------- Ran 1 test in 5.768s OK """So it's not only tmpfs. I ran the test on ci-worker-ppc64el-05 (no other tests were running at the time) with adapted timeout. If I reduce the current 3 sec copy-timeout to 1 sec the test passes (2 seconds is too long, only int allowed). If I try the same thing in the opposite direction on ci-worker13, raising to 4 seconds causes failure in the """self.assertLess(huge_size, 10000000000)""", with bumping to 5 seconds fails in the same way. ci-worker13 was running quite some tests at the same time, not sure if that's related.
Anyways, it looks like we could just lower the timeout to 1 second and hope were fine for some time to come.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
