Hi,

Some time ago, I already experienced on my own laptop that --shell and
--shell-fail didn't work anymore like they used to, but I feared I 
messed to much while developing autopkgtest. However, today I ran
autopkgtest on one of the ci.d.n hosts to provide a testbed for
debugging to someone, but the shell I got with --shell-fail didn't work.
The shell gives a prompt, but doesn't do anything with the input. I
stopped the shell in the end with Ctrl-C. I could reproduce with
src:hello and debugging info on my system too, see the attached log.

Paul

autopkgtest [09:54:00]: test unit-tests-server:  - - - - - - - - - -
results - - - - - - - - - -
unit-tests-server    FAIL non-zero exit status 1
autopkgtest [09:54:00]:  - - - - - - - - - - running shell - - - - - - -
- - -
root@elbrus:/tmp/autopkgtest-lxc.iolc4ahc/downtmp/build.tDD/src# apt
install tmate




^CTraceback (most recent call last):
   File "/usr/bin/autopkgtest", line 911, in <module>
     main()
   File "/usr/bin/autopkgtest", line 899, in main
     process_actions()
   File "/usr/bin/autopkgtest", line 854, in process_actions
     run_tests(tests, tests_tree)
   File "/usr/bin/autopkgtest", line 199, in run_tests
     testbed.run_test(tree, t, opts.env, opts.shell_fail, opts.shell,
   File "/usr/share/autopkgtest/lib/adt_testbed.py", line 1406, in run_test
     self.run_shell(tree.tb, ['AUTOPKGTEST_ARTIFACTS="%s"' % test_artifacts,
   File "/usr/share/autopkgtest/lib/adt_testbed.py", line 1145, in run_shell
     self.command('shell', [cwd or '/'] + extra_env)
   File "/usr/share/autopkgtest/lib/adt_testbed.py", line 705, in command
     ll = self.expect('ok', nresults)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/share/autopkgtest/lib/adt_testbed.py", line 668, in expect
     line = self.sp.stdout.readline()
            ^^^^^^^^^^^^^^^^^^^^^^^^^
KeyboardInterrupt

I can confirm this behavior, which I encountered when fixing LxcRunner
tests, however I only hit it when the lxc virt server. I did not use
a-virt-lxc that much until recently, so I can't tell when it stopped
working.

I worked around the issue by manually running `lxc-attach containername`
to jump into the container.

Hi

So you're saying it doesn't happen with qemu? I recall I had it there
too, but I might be misremembering.

Paul

qemu doesn't try to directly open a shell, it gives the following output
and those methods normally work for me:

[...]
autopkgtest [10:35:51]:  - - - - - - - - - - running shell - - - - - - - - - -
You can now log into the VM through the serial terminal.
Depending on which terminal program you have installed, you can use one of

    ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022 user@localhost
    minicom -D unix#/tmp/autopkgtest-qemu._eh9zmf4/ttyS0
    nc -U /tmp/autopkgtest-qemu._eh9zmf4/ttyS0
    socat - UNIX-CONNECT:/tmp/autopkgtest-qemu._eh9zmf4/ttyS0

The tested source package is in /tmp/autopkgtest.yg4J9u/build.ZDI/real-tree

Press Enter to resume running tests.

Hi,

Right, I probably experienced this with qemu when I was working on my
commands-via-ssh implementation and thought it was due to that.

Paul