@@ -134,6 +134,13 @@ export VALGRIND_QEMU=
export IMGKEYSECRET=
export IMGOPTSSYNTAX=false
+# Save current tty settings, since an aborting qemu call may leave things
+# screwed up
+STTY_RESTORE=
+if test -t 0; then
+ STTY_RESTORE=$(stty -g)
+fi
+
for r
do
@@ -664,6 +671,9 @@ END { if (NR > 0) {
needwrap=false
fi
+ if test -n "$STTY_RESTORE"; then
+ stty $STTY_RESTORE
+ fi
rm -f "${TEST_DIR}"/*.out "${TEST_DIR}"/*.err "${TEST_DIR}"/*.time
rm -f "${TEST_DIR}"/check.pid "${TEST_DIR}"/check.sts
rm -f $tmp.*
Executing qemu with a terminal as stdin will temporarily alter stty settings on that terminal (for example, disabling echo), because of how we run both the monitor and any multiplexing with guest input. Normally, qemu restores the original settings on exit; but if an iotest triggers qemu to abort in the middle, we can be left with the altered terminal setup. This can make life very annoying when debugging an iotest failure (not everyone remembers the trick of blind-typing 'stty sane' without echo, and some people prefer terminal settings that are slightly different than the defaults picked by 'stty sane'). It is possible to avoid qemu corrupting the terminal by not passing a terminal to qemu's stdin in the first place (as in, use './check ... </dev/null'), but that's extra typing to have to remember. But running 'exec </dev/null' in the harness seems like it might be too heavy of a hammer. So I instead went the the solution of saving and restoring the stty settings, only when the harness detects that it is run interactively. I tested this patch by forcing an allocation failure (I can't guarantee that this particular limit will work on all setups, but it shows the idea): $ (ulimit -S -v 500000; ./check -qcow2 1) Signed-off-by: Eric Blake <eblake@redhat.com> --- v3: new patch --- tests/qemu-iotests/check | 10 ++++++++++ 1 file changed, 10 insertions(+)