virtme
virtme copied to clipboard
--script-sh breaks with /dev/null or closed stdin
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
?
Might this problem be resolved by https://github.com/amluto/virtme/pull/80?
@lmb would you try using https://github.com/arighi/virtme and checking if the problem is gone?
I don't really have a way to reproduce this anymore, sorry :(