thread 'main' panicked at 'Failed to kill child: Sys(ESRCH)' and No output from lorem example apps

[LedgeDash]

[davidliu@sns59] cat payload.json | sudo  ./target/debug/firerunner --kernel ../images/vmlinux --rootfs ../images/node-base.ext4 --appfs ../images/examples/loremjs/output.ext4
Connection from VsockAddr { port: 1024, cid: 42 }
thread 'main' panicked at 'Failed to kill child: Sys(ESRCH)', src/libcore/result.rs:999:5

Here's the backtrace:

[davidliu@sns59] cat payload.json | sudo RUST_BACKTRACE=1 ~/.cargo/bin/cargo run --bin firerunner -- --kernel ../images/vmlinux --rootfs ../images/node-base.ext4 --appfs ../images/examples/loremjs/output.ext4
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/firerunner --kernel ../images/vmlinux --rootfs ../images/node-base.ext4 --appfs ../images/examples/loremjs/output.ext4`
Connection from VsockAddr { port: 1024, cid: 42 }
thread 'main' panicked at 'Failed to kill child: Sys(ESRCH)', src/libcore/result.rs:999:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: rust_begin_unwind
             at src/libstd/panicking.rs:308
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::result::unwrap_failed
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/macros.rs:18
   9: core::result::Result<T,E>::expect
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/result.rs:827
  10: firerunner::runner::VmApp::kill
             at src/runner.rs:35
  11: <firerunner::runner::VmApp as core::ops::drop::Drop>::drop
             at src/runner.rs:46
  12: core::ptr::real_drop_in_place
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/ptr.rs:195
  13: firerunner::main
             at bins/firerunner/main.rs:177
  14: std::rt::lang_start::{{closure}}
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
  15: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  16: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:85
  17: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:394
             at src/libstd/rt.rs:48
  18: std::rt::lang_start
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
  19: main
  20: __libc_start_main
  21: _start

[LedgeDash]

This seems related to guest's rootfs and/or appfs. Using @alevy 's images didn't trigger this bug.
We should change the wait vm logic to check for vm existence, not just panicking.