Comment 8 for bug 1630578

On Tue, Jan 17, 2017 at 07:42:34AM -0000, Martin Pitt wrote:
> > If you see a kernel panic 3 times, treat that as a real failure.
>
> Sounds good!
>
> > the testsuite OOMing and killing autopkgtest itself.
>
> That is, it kills the command (i. e. debian/tests/blah) that autopkgtest
> runs over ssh? Shouldn't the console log also contain some trace of
> "OOM" which could be used as an indication that it's a real test
> failure?

Yep, you can see things being killed by the OOM killer - do you think
that autopkgtest should mark that as a failure, or the worker? If the
worker, this could be an instance of the above too. Is there something
specific we can look for being killed?

Note that autopkgtest in this case:

> ERROR - 12:55:49 ERROR| [stderr] test_regression_testsuite (__main__.ApparmorTestsuites)
> ERROR - 12:55:54 DEBUG| [stdout] preparing apparmor_2.10.95-4ubuntu5.2.dsc... done
> ERROR - 12:55:54 DEBUG| [stdout]
> ERROR - Killed
> ERROR -
> ERROR - Due to the above error(s), this script is unable to continue and is terminating.
> ERROR -
> Connection to 10.220.44.208 closed by remote host.
> Exit request sent.
> autopkgtest [13:03:42]: ERROR: testbed failure: testbed auxverb failed with exit code 255

isn't outputting the console log. I don't think that debug_failure is
surfaced all the way up to lib/adt_testbed.py, where we see this failure
- do you have an idea about how to get it out? Add a
'hook_debug_failure'?

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]