I know there’s a way to do this. When one (for instance) opens-in-dvm, the dvm starts up, and you can continue to work in the originating system.
I’ve tried tracing this but it’s just a call to qrexec-client-vm.
Try as I might, when I try to start an app in a disposable via qrexec-client-vm, my shell simply hangs there until the disposable exits. Worse, if I kill the shell I am running from, the disposable goes down.
I want to “fire and forget”: start the disposable from the command line in some VM, and then once the disposable is started, be able to issue another command. And I don’t want the disposable to die just because I close the window on the VM I launched it from!
If I understand correctly, you open an appvm and then you open a file of this appvm in a dispVM and you want to be able to close the AppVM and keep your dispVM open right? In this case, I don’t think it’s possible because your dispVM is “linked” with your AppVM, so when you close it, the dispVM closes too.
Indeed you have to keep the qrexec-client-vm process running, but you can treat it like any other long-running process that you want to detach from your (e.g. Bash) shell:
Word of warning: Even after detaching the process, you still have to keep the opener VM itself running. If you were to shut it down, there’s a bug that might cause the DisposableVM not to be killed immediately in some circumstances, but that’s unintentional and shouldn’t be relied on:
But if someone actually likes this behavior of the DisposableVM sticking around even after the opener VM shuts down, I’m saying this might not work in every scenario (because if the DisposableVM ever happens to attempt to send some data back to the opener VM, that’s when the system finally remembers to kill it as it should have done a while ago), and it will also no longer work as soon as someone figures out the reason for the delay and fixes it.
So what I am getting from this is, if I (say) open an email attachment in a disposable, and then I close the VM my email client is running in, that disposable will go away as well?
(I generally copy attachments to a disposable, then open in the disposable–for some reason I haven’t had time or need to pursue the direct route never worked for me. This is why I’ve never realized this before.)
It sounds like what I am asking for doesn’t exist. However, the more important thing is being able to get back to my command prompt in the originating qube while the spun-off qube is still running, and I may have found the magic formula for it (I spotted something in another script that seems to work and it looks a lot like what you show: qrexec-client-vm @dispvm ... </dev/null &>/dev/null & (I will have to verify this when next I sit in front of that physical machine) but I didn’t do the disown (I had no idea such a thing existed). [The key piece was those /dev/null redirections.]
I think I can accommodate having to keep the originator open in my use case; I was really only concerned with the bad consequences of having the disposable shut down unexpectedly with no chance to clean up after itself (it’s going to be used to decrypt veracrypt containers).
I think that’s the intention, except due to the linked bug it might take a while (or, in the case of qubes.OpenInVM RPC which IIRC doesn’t attempt to send back data until it’s finished anyway, it probably would look like it doesn’t happen at all).
If you need more control over the lifecycle of the disp1234, you’d have to use the admin API as previously discussed:
Ironically that was my question…and I came up with a rather crude way of solving it. In essence when I start the disposable, I pass it the host name of the qube starting it as a command line parameter.
The disposable then sends its own name back to the originator via a service call (which it will also use to report other status at other times). As I said, crude, but at least it guarantees that I have the right qube (while comparing two qvm-ls’s could mess up if some other disposable happens, due to a cron job for instance, to fire up at the same time).
So when I went to implement that and discovered I couldn’t get my command prompt back (which would mean a bash script doing this would simply stop there) I had to ask this question. After asking I stumbled upon something, but wanted to see if there was a better answer than that. Ironically it’s almost exactly the same thing you proposed.
Don’t know if it’s relevant to what you’re doing, but an RPC service can get the originator’s name from the $QREXEC_REMOTE_DOMAIN environment variable, which is provided through dom0 (and hence guaranteed to not be a lie from the originator).
