test_epoll_stdin_event fails on a1.metal when running without a tty

[alxiord]

Running the CI suite over ssh causes test_epoll_stdin_event to fail on an a1.metal instance.
Running it from a terminal works fine.

ssh ec2-user@a1.metal 'firecracker/tools/devtool -y test -- integration_tests/build/test_unittests.py'

---- tests::test_epoll_stdin_event stdout ----
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: rust_begin_unwind
             at src/libstd/panicking.rs:311
   9: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  10: core::panicking::panic
             at src/libcore/panicking.rs:49
  11: core::option::Option<T>::unwrap
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libcore/macros.rs:12
  12: vmm::tests::test_epoll_stdin_event
             at vmm/src/lib.rs:2293
  13: vmm::tests::test_epoll_stdin_event::{{closure}}
             at vmm/src/lib.rs:2289
  14: core::ops::function::FnOnce::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libcore/ops/function.rs:235
  15: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/liballoc/boxed.rs:787
  16: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  17: std::panicking::try
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/panicking.rs:275
  18: std::panic::catch_unwind
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/panic.rs:394
  19: test::run_test::run_test_inner::{{closure}}
             at src/libtest/lib.rs:1408
  20: test::run_test::run_test_inner
             at src/libtest/lib.rs:1430
  21: test::run_test
             at src/libtest/lib.rs:1449
  22: test::run_tests
             at src/libtest/lib.rs:1102
  23: test::run_tests_console
             at src/libtest/lib.rs:951
  24: test::test_main
             at src/libtest/lib.rs:294
  25: test::test_main_static
             at src/libtest/lib.rs:328
  26: vmm::main
  27: std::rt::lang_start::{{closure}}
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/rt.rs:64
  28: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:49
  29: std::panicking::try::do_call
             at src/libstd/panicking.rs:296
  30: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  31: std::panicking::try
             at src/libstd/panicking.rs:275
  32: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  33: std::rt::lang_start_internal
             at src/libstd/rt.rs:48
  34: std::rt::lang_start
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libstd/rt.rs:64
  35: main
  36: __libc_start_main
  37: <unknown>


failures:
    tests::test_epoll_stdin_event

[iulianbarbu]

I suspect that the error it is not related to an a1.metal instance, but it is related to the lack of a pseudo-terminal , which comes with running a ssh with a command (in this case the command is 'firecracker/tools/devtool -y test -- integration_tests/build/test_unittests.py'). In order to attach pseudo-terminal, I think it is enough running the ssh with command also with -t flag. I've checked it on my x86_64 machine, and it fails when I run the command without -t, and it succeeds when I am running it with -t flag.