When I run a disposable using qvm-run --service --dispvm=..., is stays attached to the current shell. I can background it with &, and even close the terminal afterwards (which doesn’t create a zombie process? cool, but this isn’t what I was expecting…).
Still, I’m having hebeegeebies about this for some reason. It feels manky. Is there no better way to background it? Is the way I’m using even bad?
Please share your thoughts.
That’s basically fine, but if you’re doing it in an interactive* Bash shell you should run the disown -h command afterwards to ensure that Bash doesn’t send the SIGHUP hangup signal to qvm-run on closing the terminal in any circumstance**. This is because qvm-run is responsible for killing the disposable after the in-qube command has finished.
* As opposed to a script
** Depending on how exactly you close it, whether the shell is a login shell, and the state of the huponexit shell option
Not really, at least not for the all-in-one command that creates a new disp1234 disposable, runs something in it, and kills it.
Are there alternatives? I don’t think qvm-start can do this, and even if it can I still need to run stuff in this disposable, not just start it. I guess the real alternative would be to write my own thing using qubes admin API. I shelved it for now.
Yep, to get those disp1234 disposables you’d have to resort to the admin API:
disp_template=dom0 # here, dom0 means use the default disposable template
readarray -d '' -s 1 disp < <(qubesd-query --empty --fail dom0 admin.vm.CreateDisposable "$disp_template")
wait $! || ... # handle error
qvm-start "$disp" # optional
qvm-run "$disp" ...
...
qvm-kill "$disp"
qvm-run will still run in the foreground though. You could use the lower-level qrexec-client -e instead if that’s a problem. (Not sure about combining -e with a service call, so I’ve deleted the example)