Package: autopkgtest
Version: 5.5
Severity: normal

Hey,

We don't have much information to help with debugging of this problem. I
just wanted to make sure it is recorded.

We've got an autopkgtest process that is currently (Sep 7) still
running, when it was started:

  Aug 25 07:44:36 juju-prod-ues-proposed-migration-machine-11 sh[31372]: 
2018-08-25 07:44:36,816 [31372] INFO: Received request for package 
r-cran-fastmatch on cosmic/ppc64el; params: {'triggers': 
['glibc/2.28-0ubuntu1']}
  Aug 25 07:44:36 juju-prod-ues-proposed-migration-machine-11 sh[31372]: 
2018-08-25 07:44:36,817 [31372] INFO: Running 
/home/ubuntu/autopkgtest/runner/autopkgtest --output-dir 
/tmp/autopkgtest-work.fdcdgul6/out --timeout-copy=6000 --setup-commands 
/home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh 
--setup-commands /home/ubuntu/autopkgtest/setup-commands/setup-testbed 
--apt-pocket=proposed=src:glibc --apt-upgrade r-cran-fastmatch 
--env=ADT_TEST_TRIGGERS=glibc/2.28-0ubuntu1 -- ssh -s 
/home/ubuntu/autopkgtest/ssh-setup/nova -- --nova-reboot --flavor autopkgtest 
--security-groups autopkgtest@bos02-ppc64el-20.secgroup --name 
adt-cosmic-ppc64el-r-cran-fastmatch-20180825-074436 --image 
adt/ubuntu-cosmic-ppc64el-server --keyname 
testbed-juju-prod-ues-proposed-migration-machine-11 
--net-id=net_ues_proposed_migration -e 'http_proxy=http://squid.internal:3128' 
-e 'https_proxy=http://squid.internal:3128' -e 
'no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,changelogs.ubuntu.com,ddebs.ubuntu.com,ppa.launchpad.net'
 --mirror=http://ftpmaster.internal/ubuntu

a long time ago.

I was away at the time, but apparently this affected several instances
around the same time, so it is likely that some event disrupted the
tests and they should have failed / been retried. Unfortunately the logs
have been deleted since then, so I can't see if there is any evidence in
them. If that's true then there might be an additional bug that they
didn't fail harder. This one says that the timeout should be there as an
ultimate fallback.

We're running 5243905d9dbee07d2b712d747fea0decd6e0c78c, so it's a bit
old - but scanning the changes doesn't show anything that's likely to
have changed this. Do let me know if that's wrong though. I'll try to
update us soon in any event.

Cheers!

-- 
Iain Lane                                  [ i...@orangesquash.org.uk ]
Debian Developer                                   [ la...@debian.org ]
Ubuntu Developer                                   [ la...@ubuntu.com ]

Reply via email to