New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dispvms fail to start due to missing WaitForSession #3288

Closed
qubesuser opened this Issue Nov 7, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@qubesuser

qubesuser commented Nov 7, 2017

Qubes OS version:

R4.0-rc2

Steps to reproduce the behavior:

  1. Start dispvm with qvm-run --dispvm -p xterm

Expected behavior:

The dispvm is run and xterm appears.

Actual behavior:

Sometimes it fails with this message:
xterm: Xt error: Can't open display: :0

General notes:

The reason is that WaitForSession is not used for dispvms, which means that sometimes the application starts before the X server.

This is because dispvms die after the first qrexec calls, so it's not possible to make two calls (I'm not sure why it was thought to be fine to just skip the call - perhaps because in Qubes 3.2 dispvms started from savefiles that would always be taken after the session is up).

I think this could be solved by adding a "special" qubes.WaitForSession when starting dispvms internally in the qubesd code.

Another option is to add a new qubes.SessionVMShell that waits for the session to be up and then runs qubes.VMShell

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Nov 7, 2017

Member

This is a duplicate of #3012. The solution here is to start GUI applications using qubes.StartApp service, which include waiting for session.

Member

marmarek commented Nov 7, 2017

This is a duplicate of #3012. The solution here is to start GUI applications using qubes.StartApp service, which include waiting for session.

@jpouellet

This comment has been minimized.

Show comment
Hide comment
@jpouellet

jpouellet Dec 12, 2017

Contributor

This is a duplicate of #3012. The solution here is to start GUI applications using qubes.StartApp service, which include waiting for session.

That only works if the target VM already happens to have a .desktop file for what you want to do. I can think of many legitimate use cases where this may not be true (for example: specifying arguments, specific fallback programs depending on what's installed, etc.)

Contributor

jpouellet commented Dec 12, 2017

This is a duplicate of #3012. The solution here is to start GUI applications using qubes.StartApp service, which include waiting for session.

That only works if the target VM already happens to have a .desktop file for what you want to do. I can think of many legitimate use cases where this may not be true (for example: specifying arguments, specific fallback programs depending on what's installed, etc.)

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Dec 12, 2017

Member

Well, if you want to start GUI application which have no .desktop file, in DispVM, you can also prepend echo user | /etc/qubes-rpc/qubes.WaitForSession; to the command. Or... create a .desktop file for it. Generally the less we use qubes.VMShell (or other over-powered service) the better.

Member

marmarek commented Dec 12, 2017

Well, if you want to start GUI application which have no .desktop file, in DispVM, you can also prepend echo user | /etc/qubes-rpc/qubes.WaitForSession; to the command. Or... create a .desktop file for it. Generally the less we use qubes.VMShell (or other over-powered service) the better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment