qvm-run blocks Dom0 terminal in R4

[Bill Wether]

Hi, all,

In 3.2's dom0, typing

qvm-run -a work konsole

returns as soon as the VM has started up and the command has been issued.

In R4, though, the Dom0 terminal just gets stuck--I can get it back with ctl-C, but that's pretty inelegant. I can use setsid, but that just disguises the problem since all those bash sessions are still there.

Was this a design choice, is it a bug, or (as so often) pilot error?

Thanks

BillW

[awokd]

Design choice. Try appending a " &" after the command string.

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bill Wether:

Not quite sure. But you can use a lower-level command instead of
qvm-run to get R3.2-like behavior:

$ /usr/lib/qubes/qrexec-client -e -d work 'DEFAULT:konsole'

'-e means exit after sending cmd', in this case konsole for the
default user.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJasX1AXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfuPAP/3JYcfzfxdZLvCm+t7QRG4B+
S1dRN5WsSmIGYdCp+P3o1W2VMzgHfxJ9Qlf+yxEToF+mV2zBZTYSCbKT3YW7e3VL
soS8YCW3q5lm2AQ+n2v/TruRUgUTs/rDZ5MgHh7CnP8/0/pLkT93GMlY0RjChFzr
8YGyyRntSrl+I7FcWoSccWQSGcbYZUjfZc2lJLugT4xlyKuwsTVMdRoMzmvR7YG4
qK1szVBwQoiblmu21hvUa1icIlDgawiioRpQLnmHWV/ucV+9r9Qp00eAydLZrwPo
omEMM7ykfMzP2/8cKYUo8OTj+lmDwSmwTP6xkoIb4qrLwuLdnWcF4/GufTEQAbTx
GYPvupDcvX3ZaCss9/sKBbNdGA1IJx1q2UEhhTYjtIsW2GVR86ogLoqSqHUQ0Mz/
hZY0zO/IktsXXYOklt169H5p/2zF7zRNHYFTAu991UkxL8dDNUyix/ZDdRfBtgNZ
REMkKqTEkZ1J+yu3hVjQLino7LbWtqevIMpDYGNvyGVH8F1jjdw6VxPLN8yddwkV
/aN6TXgLg8kJlLsYFWENIHWLINpJ8Cs2dshVfBCyVu9/llBNQFtMbJwi0euoRUl6
cspzotdgyXhII5oYdzrZvs3whSvcAhwcztf9lafpsoaq5gYdXNXKHT3bTN12uHOI
k8x7vpb0fHqaa5JTBtfs
=587Y
-----END PGP SIGNATURE-----

[Bill Wether]

Could you give me a few more words about that? Running it in the background is like setsid, except that the cruft stays in the same process.

ISTM that 'qvm-run' should just run the program in the VM, if necessary starting the VM first. What's it doing, waiting for a return code?

Cheers

BillW

[awokd]

On Wed, March 21, 2018 2:33 am, Bill Wether wrote:
> On Tuesday, March 20, 2018 at 3:08:13 PM UTC-4, awokd wrote:

>> Design choice. Try appending a " &" after the command string.
>>
>
>
> Could you give me a few more words about that? Running it in the
> background is like setsid, except that the cruft stays in the same
> process.

Marek said somewhere (mailing list? issue?) that this was a design choice
for 4. Can't recall exactly where though!

> ISTM that 'qvm-run' should just run the program in the VM, if necessary
> starting the VM first. What's it doing, waiting for a return code?

I believe it's waiting on a return code, yes. It makes sense for running
one-shot programs in a VM. Of course, longer running programs involving
user input will take longer to return on exit. Sorry, don't have much more
details than that.