/qubes-issues

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

Error message "qrexec not connected" when quickly opening several applications in powered off AppVM #2001

Closed
ghost opened this Issue May 18, 2016 · 4 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
  Release 3.2 updates
4 participants
@andrewdavidwong @adrelanos @qubesos-bot @marmarek
@ghost

ghost commented May 18, 2016 •
edited by ghost
Edited 1 time
  • @ghost ghost edited May 18, 2016 (most recent)

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

R3.1

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

Probably all (tested with debian-8 and whonix-ws AppVMs)

Expected behavior:

Both applications start after the AppVM is powered up.

Actual behavior:

Only the first application is started and the error message "[d]omain [domain]: qrexec not connected" can be read if hovering above the error triangle.

Steps to reproduce the behavior:

Try to quickly start two, or more, applications in a currently powered off AppVM.

General notes:

Related issues:

Relevant labels:

  • Bug
@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong May 18, 2016

Member

I'm unable to reproduce this on whonix-ws-based VMs. It sounds like it may be a more general VM startup issue.
Member

andrewdavidwong commented May 18, 2016

I'm unable to reproduce this on whonix-ws-based VMs. It sounds like it may be a more general VM startup issue.
@adrelanos

This comment has been minimized.

Show comment
Hide comment
@adrelanos

adrelanos May 18, 2016

Member

It happens when clicking two applications to start them in one VM currently powered off VM too quickly. The bug description gets clearer when translating it into cli terms. How to reproduce:

qvm-run -q --tray -a pdf -- 'qubes-desktop-run /usr/share/applications/kde4/konsole.desktop' &

qvm-run -q --tray -a pdf -- 'qubes-desktop-run /usr/share/applications/gnome-terminal.desktop'

ERROR(pdf): Domain 'pdf': qrexec not connected.
Member

adrelanos commented May 18, 2016

It happens when clicking two applications to start them in one VM currently powered off VM too quickly. The bug description gets clearer when translating it into cli terms. How to reproduce:

qvm-run -q --tray -a pdf -- 'qubes-desktop-run /usr/share/applications/kde4/konsole.desktop' &

qvm-run -q --tray -a pdf -- 'qubes-desktop-run /usr/share/applications/gnome-terminal.desktop'

ERROR(pdf): Domain 'pdf': qrexec not connected.
@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong May 18, 2016

Member

Ah, thank you. I can reproduce it now.
Member

andrewdavidwong commented May 18, 2016

Ah, thank you. I can reproduce it now.

@andrewdavidwong andrewdavidwong added bug C: core P: minor labels May 18, 2016

@andrewdavidwong andrewdavidwong added this to the Release 3.1 milestone May 18, 2016

@ghost ghost changed the title from "qrexec not connected" erro when open two applications in powered off AppVMs to Error message "qrexec not connected" when opening two applications quickly in powered off AppVM May 18, 2016

@ghost ghost changed the title from Error message "qrexec not connected" when opening two applications quickly in powered off AppVM to Error message "qrexec not connected" when quickly opening several applications in powered off AppVM May 18, 2016

@marmarek marmarek modified the milestones: Release 3.1, Release 3.1 updates Nov 19, 2016

@andrewdavidwong andrewdavidwong referenced this issue Mar 5, 2017

Open

Domain '[whichever appVM]': qrexec not connected. #2667

@andrewdavidwong andrewdavidwong modified the milestones: Release 3.1 updates, Release 3.2 updates May 31, 2017

marmarek added a commit to marmarek/qubes-core-admin that referenced this issue Jun 3, 2017

@marmarek
vm: avoid starting the same VM multiple times simultaneously 
While libvirt handle locking itself, there is also Qubes-specific
startup part. Especially starting qrexec-daemon and waiting until
qrexec-agent connect to it. When someone will attempt to start VM the
second time (or simply assume it's already running) - qrexec will not be
connected yet and the operation will fail. Solve the problem by wrapping
the whole vm.start() function with a lock, including a check if VM is
running and waiting for qrexec.

Also, do not throw exception if VM is already running.

This way, after a call to vm.start(), VM will be started with qrexec
connected - regardless of who really started it.
Note that, it will not solve the situation when someone check if VM is
running manually, like:

    if not vm.is_running():
        yield from vm.start()

Such code should be changed to simply:

    yield from vm.start()

Fixes QubesOS/qubes-issues#2001
Fixes QubesOS/qubes-issues#2666
Verified
This commit was signed with a verified signature.
@marmarek marmarek Marek Marczykowski-Górecki
GPG key ID: 063938BA42CFA724 Learn about signing commits
0209e19

marmarek added a commit to marmarek/qubes-core-admin that referenced this issue Jun 3, 2017

@marmarek
vm: avoid starting the same VM multiple times simultaneously 
While libvirt handle locking itself, there is also Qubes-specific
startup part. Especially starting qrexec-daemon and waiting until
qrexec-agent connect to it. When someone will attempt to start VM the
second time (or simply assume it's already running) - qrexec will not be
connected yet and the operation will fail. Solve the problem by wrapping
the whole vm.start() function with a lock, including a check if VM is
running and waiting for qrexec.

Also, do not throw exception if VM is already running.

This way, after a call to vm.start(), VM will be started with qrexec
connected - regardless of who really started it.
Note that, it will not solve the situation when someone check if VM is
running manually, like:

    if not vm.is_running():
        yield from vm.start()

Such code should be changed to simply:

    yield from vm.start()

Fixes QubesOS/qubes-issues#2001
Fixes QubesOS/qubes-issues#2666
Verified
This commit was signed with a verified signature.
@marmarek marmarek Marek Marczykowski-Górecki
GPG key ID: 063938BA42CFA724 Learn about signing commits
c98481b

marmarek added a commit to marmarek/qubes-core-admin that referenced this issue Jun 3, 2017

@marmarek
vm: avoid starting the same VM multiple times simultaneously 
While libvirt handle locking itself, there is also Qubes-specific
startup part. Especially starting qrexec-daemon and waiting until
qrexec-agent connect to it. When someone will attempt to start VM the
second time (or simply assume it's already running) - qrexec will not be
connected yet and the operation will fail. Solve the problem by wrapping
the whole vm.start() function with a lock, including a check if VM is
running and waiting for qrexec.

Also, do not throw exception if VM is already running.

This way, after a call to vm.start(), VM will be started with qrexec
connected - regardless of who really started it.
Note that, it will not solve the situation when someone check if VM is
running manually, like:

    if not vm.is_running():
        yield from vm.start()

Such code should be changed to simply:

    yield from vm.start()

Fixes QubesOS/qubes-issues#2001
Fixes QubesOS/qubes-issues#2666
Verified
This commit was signed with a verified signature.
@marmarek marmarek Marek Marczykowski-Górecki
GPG key ID: 063938BA42CFA724 Learn about signing commits
150b429

@marmarek marmarek closed this in marmarek/qubes-core-admin@018877a Jun 12, 2017

@qubesos-bot

This comment has been minimized.

Show comment
Hide comment
@qubesos-bot

qubesos-bot Jul 4, 2017

Automated announcement from builder-github

The package qubes-core-dom0-4.0.1-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

qubesos-bot commented Jul 4, 2017

Automated announcement from builder-github

The package qubes-core-dom0-4.0.1-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

@qubesos-bot qubesos-bot added the r4.0-dom0-cur-test label Jul 4, 2017

@qubesos-bot qubesos-bot referenced this issue in QubesOS/updates-status Jul 4, 2017

Closed

core-admin v4.0.1 (r4.0) #100

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