Disposable VM gained persistance!

[tezeb]

Qubes OS version (e.g., R3.2): R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable): archlinux

---

Expected behavior:

When process for which dvm has been started exits, dvm shall be stopped and removed.

Actual behavior:

Most of the time it works, but sometimes the dvm stays open. It's even possible to shut it down and start again.

Steps to reproduce the behavior:

N/A, it happens randomly and I am not able to reproduce it.

General notes:

I can provide some logs(but which?), as I have such dvm running in my system right now.

---

Related issues:

[jpouellet]

Is this distinct from #2200? (You have updated since then... right?)

[jpouellet]

Is this distinct from #2200? (You have updated since then... right?)

[tezeb]

Yes I did. And it seems distinct.
It's not persistence of DispVM filesystem, rather that DispVM does not get shutdown and removed automatically. Also it's possible to shut it down and it is as usable as other AppVMs are.

[tezeb]

Yes I did. And it seems distinct.
It's not persistence of DispVM filesystem, rather that DispVM does not get shutdown and removed automatically. Also it's possible to shut it down and it is as usable as other AppVMs are.

[rustybird]

That seems familiar... In the context of Split Browser, I've seen DisposableVMs lingering around for no discernible reason, occasionally.

[rustybird]

That seems familiar... In the context of Split Browser, I've seen DisposableVMs lingering around for no discernible reason, occasionally.

[tezeb]

@rustybird was it on ArchLinux template or something else?

[tezeb]

@rustybird was it on ArchLinux template or something else?

[rustybird]

In my case, it was a whonix-ws template.

[rustybird]

In my case, it was a whonix-ws template.

[jpouellet]

Hmmm... I just observed this too with a fedora-24 based vm.

/tmp/qubes-session-waiter had 2 PIDs, both were dead.

[jpouellet]

Hmmm... I just observed this too with a fedora-24 based vm.

/tmp/qubes-session-waiter had 2 PIDs, both were dead.

[mig5]

I can reproduce this reliably by running from the dom0 shell:

echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red

The dispVM terminal pops up. I exit the terminal and sometimes the dom0 command which doesn't exit, hangs for a moment. If I Ctrl+C that process in dom0, I get the KeyBoardInterrupt python exception and the dispVM is still running.

(Or I can just ctrl+C in the dom0 without bothering to exit the DispVM shell even, and it remains running even after the dom0 command has cancelled)

If I then shutdown the dispVM via Qubes Manager, it 'persists' in the list of VMs.

So in general I would say if there is something that can cause /usr/lib/qubes/qfile-daemon-dvm to throw an exception instead of cleaning up on a clean exit, there is the chance the VM can linger.

[mig5]

I can reproduce this reliably by running from the dom0 shell:

echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red

The dispVM terminal pops up. I exit the terminal and sometimes the dom0 command which doesn't exit, hangs for a moment. If I Ctrl+C that process in dom0, I get the KeyBoardInterrupt python exception and the dispVM is still running.

(Or I can just ctrl+C in the dom0 without bothering to exit the DispVM shell even, and it remains running even after the dom0 command has cancelled)

If I then shutdown the dispVM via Qubes Manager, it 'persists' in the list of VMs.

So in general I would say if there is something that can cause /usr/lib/qubes/qfile-daemon-dvm to throw an exception instead of cleaning up on a clean exit, there is the chance the VM can linger.

[marmarek]

/usr/lib/qubes/qfile-daemon-dvm process is responsible for cleaning up DispVM, so it is not surprising at all that if you kill it, DispVM is not cleaned up.

So in general I would say if there is something that can cause /usr/lib/qubes/qfile-daemon-dvm to throw an exception instead of cleaning up on a clean exit, there is the chance the VM can linger.

Yes, this is right question. If the DispVM was started from menu, check ~/.xsession-errors. If from other VM - check its qrexec log (/var/log/qubes/).

[marmarek]

/usr/lib/qubes/qfile-daemon-dvm process is responsible for cleaning up DispVM, so it is not surprising at all that if you kill it, DispVM is not cleaned up.

So in general I would say if there is something that can cause /usr/lib/qubes/qfile-daemon-dvm to throw an exception instead of cleaning up on a clean exit, there is the chance the VM can linger.

Yes, this is right question. If the DispVM was started from menu, check ~/.xsession-errors. If from other VM - check its qrexec log (/var/log/qubes/).