--script-sh breaks with /dev/null or closed stdin

[lmb]

This is probably an upstream QEMU bug, but I think it'd be good to try and find a work around. The following command hangs indefinitely:

$ virtme-run --show-boot-console --kimg linux-5.2-rc4.bz --script-sh "echo foo" < /dev/null
...
[    2.121087] virtme-init: udev is done
[    2.237338] ip (184) used greatest stack depth: 12488 bytes left
[    2.246030] virtme-init: starting script

If I change virtme-init to strace what is happening, I can see that the script is hanging on writing "foo". Removing < /dev/null makes everything work again.

Usually I wouldn't care, but Docker also redirects stdin to /dev/null. On previous QEMU versions it was possible to work around this by closing stdin via 0<&-, but as of 3.1.0 this breaks.

There is a work-around however:

$ virtme-run --show-boot-console --kimg linux-5.2-rc4.bz --script-sh "echo foo" < /dev/zero

This might end up flooding stdin with zeros, so I'm not sure what the implications of this are. cat | virtme-run doesn't work, since cat just exits due to stdin being /dev/null, which leads to stdin to QEMU being closed.

• Is there a way to fix this behaviour from virtme-init or similar?
• If not, is there a better work around than /dev/zero?

[zevweiss]

Might this problem be resolved by https://github.com/amluto/virtme/pull/80?

[marcosps]

@lmb would you try using https://github.com/arighi/virtme and checking if the problem is gone?

[lmb]

I don't really have a way to reproduce this anymore, sorry :(