Hi Thibaut, Thanks for investigating.
On 23-09-2021 13:44, Thibaut Paumard wrote: > Note that this is apparently different from what the debci > infrastructure does (apparently recompiling instead of taking the binaries). We don't recompile unless "build-needed" is in the restrictions. We do run in lxc instead of chroot. > I then ran the test from this chroot (as sbuild user): > autopkgtest -B --test-name=gyoto-mpi -- null You can see from the top of the log that we ran with: --no-built-binaries '--setup-commands=echo '"'"'gyoto testing/i386'"'"' > /var/tmp/debci.pkg 2>&1 || true' '--setup-commands=echo '"'"'Acquire::Retries "10";'"'"' > /etc/apt/apt.conf.d/75retry 2>&1 || true' --user debci --apt-upgrade '--add-apt-source=deb http://incoming.debian.org/debian-buildd buildd-unstable main contrib non-free' --add-apt-release=unstable --pin-packages=unstable=src:mpi4py,src:openmpi --output-dir /tmp/tmp.irEl4X24YS/autopkgtest-incoming/testing/i386/g/gyoto/15316145 gyoto -- lxc --sudo --name ci-262-d8ad913b autopkgtest-testing-i386 > I note that the test suite can take a long time to run and that the > final line in the failure log for this test reads: > > mpirun.openmpi noticed that process rank 1 with PID 0 on node > ci-262-d8ad913b exited on signal 9 (Killed). > > This happens after this test has been running for 1h and 55min. > > Could it be that the process is killed because of a timeout in the test > environment? The autopktest timeout is at 2:47, so if anything this is a timeout inside the test. > Anyway, there's not much more I can do, except skip this test. Can we get more logging? I can run something in the testbed if it helps debugging the issue. > I'm reassigning to openmpi because, on the debci infrastructure, the > same failure occurs with openmpi/unstable also with mpi4py/testing. Ack, I was informed out-of-band that the likely culpit was there. Paul
OpenPGP_signature
Description: OpenPGP digital signature
