"qvm-run --service --dispvm -- qubes.StartApp+..." sometimes fails with "vchan connection timeout" under high load

[rustybird]

Qubes OS version:

R4.0rc3 (current-testing)

Affected TemplateVMs:

fedora-25

Steps to reproduce the behavior:

Run in dom0 (while starting another VM in parallel to increase system load):

qvm-run -p --dispvm -- 'i=1; until xterm -e "echo try $((i++)); read"; do sleep 0.1; done'

Or in any VM:

qvm-run-vm --dispvm    'i=1; until xterm -e "echo try $((i++)); read"; do sleep 0.1; done'

Expected behavior:

An xterm opens, printing try 1.

Actual behavior:

An xterm opens, often printing a number higher than 1 (and repeated xterm: Xt error: Can't open display: :0 error messages in the caller's terminal). It happens more frequently when the system is under high load.

General notes:

This is also seems to affect the start menu DispVM entries.

[marmarek]

This is duplicate of #3012

This is also seems to affect the start menu DispVM entries.

If that's really the case, it is separate issue (from this and #3012). Menu entries use qubes.StartApp service, which shouldn't be affected by this problem.

[marmarek]

This is duplicate of #3012

This is also seems to affect the start menu DispVM entries.

If that's really the case, it is separate issue (from this and #3012). Menu entries use qubes.StartApp service, which shouldn't be affected by this problem.

[rustybird]

This is duplicate of #3012

Sorry about that.

This is also seems to affect the start menu DispVM entries.

If that's really the case, it is separate issue (from this and #3012).

Right, qvm-run --pass-io --service --dispvm=fedora-25-dvm -- qubes.StartApp+xterm prints vchan connection timeout in this case. (Increasing the qrexec_timeout of fedora-25-dvm didn't help.)

[rustybird]

This is duplicate of #3012

Sorry about that.

This is also seems to affect the start menu DispVM entries.

If that's really the case, it is separate issue (from this and #3012).

Right, qvm-run --pass-io --service --dispvm=fedora-25-dvm -- qubes.StartApp+xterm prints vchan connection timeout in this case. (Increasing the qrexec_timeout of fedora-25-dvm didn't help.)

[marmarek]

Do you have any more details in journalctl? If you see DispVM name there, check /var/log/xen/console/guest-NAME_OF_THAT_DISPVM.log

[marmarek]

Do you have any more details in journalctl? If you see DispVM name there, check /var/log/xen/console/guest-NAME_OF_THAT_DISPVM.log

[rustybird]

guest-dispNNNN.log was always identical to a successful launch, but looking at journalctl, apparently I was simply out of memory. If I control for that, everything works fine, even while starting many VMs in parallel to qvm-run.

[rustybird]

guest-dispNNNN.log was always identical to a successful launch, but looking at journalctl, apparently I was simply out of memory. If I control for that, everything works fine, even while starting many VMs in parallel to qvm-run.