Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Attempting to open more than ~40 terminal windows results in qvm-run error "command failed with code: 1" #5969

Closed
lczerner opened this issue Jul 27, 2020 · 7 comments
Closed

Attempting to open more than ~40 terminal windows results in qvm-run error "command failed with code: 1" #5969

lczerner opened this issue Jul 27, 2020 · 7 comments
Labels
C: core eol-4.0 Closed because Qubes 4.0 has reached end-of-life (EOL) P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.
Milestone
Release 4.0 updates

Comments

@lczerner
Copy link

Qubes OS version
R4.0

Affected component(s) or functionality
qvm-run fails with code 1. After some time using the system or enough open windows I can't open any more using qvm-run

Brief summary
I am using i3 and a lots of urxvt terminals among other things spread though 6 VMs. When I open enough windows (nothing crazy maybe 40 or so) I can't open any more regardless of the vm I am using.
Most of the time, closing some of the terminals helps and I can open something else again.

To Reproduce
Keep opening terminal windows in VM until you can't open any more - for me it varies, but at the moment the limit is around 40 after which qvm-run fails with code 1.
I can still open more windows from the VM terminal (urxvt& for example) without any problem. By my shortcut (alt+enter) does not work anymore.

Expected behavior
Being able to open "unlimited" amount of windows, or at least as much as my system memory allows. I have 32GB of RAM in the system and I still have enough free memory in the VM.

Actual behavior
qvm-run fails with code 1
@lczerner lczerner added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug labels Jul 27, 2020
@andrewdavidwong andrewdavidwong added C: core needs diagnosis Requires technical diagnosis from developer. Replace with "diagnosed" or remove if otherwise closed. labels Jul 28, 2020
@andrewdavidwong andrewdavidwong added this to the Release 4.0 updates milestone Jul 28, 2020
@andrewdavidwong andrewdavidwong changed the title qvm-run: command failed with code: 1 Attempting to open more than ~40 terminal windows results in qvm-run error "command failed with code: 1" Jul 28, 2020
@marmarek
Copy link
Member

marmarek commented Aug 6, 2020

This seems to be related to #5343
Generally qrexec connections use inter-VM shared memory which is limited resource. But in fact, you don't need to keep open connection for xterm. For example: qvm-run VMNAME "xterm </dev/null &>/dev/null & :"
Qrexec protocol does support just launching a process without keeping the connection open (without this shell boilerplate), but I think it isn't exposed in qvm-run tool right now.

@lczerner
Copy link
Author

This seems to be related to #5343
Generally qrexec connections use inter-VM shared memory which is limited resource. But in fact, you don't need to keep open connection for xterm. For example: qvm-run VMNAME "xterm </dev/null &>/dev/null & :"

This seems to be working quite fine, thank you. Is that something that should be done for qubes-i3-sensible-terminal ? I am happy to send a patch if it helps.

-Lukas

@marmarek
Copy link
Member

Yes, that could be helpful.
Note there is one case where keeping connection open is desirable: when running in DispVM. DispVM is destroyed when that one service closes the connection. Is qubes-i3-sensible-terminal used to open disposable VMs too?

@lczerner
Copy link
Author

AFAICT it is only useful for situations when there is already a vm window avaliable, so the vm must be running. On the other hand I can imagine the situation where I run a program (lets say Firefox) in DispVM, then open a terminal using qubes-i3-sensible-terminal and then close the Firefox later on. Based on your comment I assume the vm will be destroed at that point, regardless of opened terminal. Not sure if that matters much ?
I could possible extract the information about the vm type from the _QUBES_VMNAME(STRING) but that looks like a dirty solution to me.

@marmarek
Copy link
Member

Based on your comment I assume the vm will be destroed at that point, regardless of opened terminal.

Yes, that's right. In this case, it doesn't matter whether qubes-i3-sensible-terminal keeps the connection or not - it looks only for the initial connection that created the DispVM (firefox in this case).

lczerner added a commit to lczerner/qubes-desktop-linux-i3-settings-qubes that referenced this issue Aug 27, 2020
@lczerner
qubes-i3-sensible-terminal: use qrexec-client directly
437586c 
Currently qvm-run is used to start a terminal in a vm. However this will
keep stdin/stdout connected depleting inter-VM shared memory which is
a limited resource (as pointed out by Marek Marczykowski-Górecki).

To avoid this use qrexec-client directly with "-e" option to avoid
connecting stdin/stdout.

This should be fine since a running vm is already required to be able to
use qubes-i3-sensible-terminal.

QubesOS/qubes-issues#5969
Signed-off-by: Lukas Czerner <[email protected]>
@lczerner lczerner mentioned this issue Aug 27, 2020
Merged
@lczerner
Copy link
Author

Sorry for the delay due to my holiday. I did send a PR that solves this issue for me by using qrexec-client directly. Let me know what you think.

Thanks!
-Lukas

lczerner added a commit to lczerner/qubes-desktop-linux-i3-settings-qubes that referenced this issue Aug 27, 2020
@lczerner
qubes-i3-sensible-terminal: use qrexec-client directly
fd44e40 
Currently qvm-run is used to start a terminal in a vm. However this will
keep stdin/stdout connected depleting inter-VM shared memory which is
a limited resource (as pointed out by Marek Marczykowski-Górecki).

To avoid this use qrexec-client directly with "-e" option to avoid
connecting stdin/stdout.

This should be fine since a running vm is already required to be able to
use qubes-i3-sensible-terminal.

QubesOS/qubes-issues#5969
Signed-off-by: Lukas Czerner <[email protected]>
lczerner added a commit to lczerner/qubes-desktop-linux-i3-settings-qubes that referenced this issue Aug 27, 2020
@lczerner
qubes-i3-sensible-terminal: use qrexec-client directly
fcbc05e 
Currently qvm-run is used to start a terminal in a vm. However this will
keep stdin/stdout connected depleting inter-VM shared memory which is
a limited resource (as pointed out by Marek Marczykowski-Górecki).

To avoid this, use qrexec-client directly with "-e" option to avoid
connecting stdin/stdout. Note that qvm-run does not support this option
at the moment, but it could be worked around by pointing stdin/stdout to
/dev/null. However using qrexec-cliend seems like a more efficient
solution in this case.

This should be fine since a running vm is already required to be able to
use qubes-i3-sensible-terminal.

QubesOS/qubes-issues#5969
Signed-off-by: Lukas Czerner <[email protected]>
@qubesos-bot qubesos-bot mentioned this issue Sep 20, 2020
Closed
@andrewdavidwong andrewdavidwong added the eol-4.0 Closed because Qubes 4.0 has reached end-of-life (EOL) label Aug 5, 2023
@github-actions
Copy link

github-actions bot commented Aug 5, 2023

This issue is being closed because:

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment.
(For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 5, 2023
@andrewdavidwong andrewdavidwong removed the needs diagnosis Requires technical diagnosis from developer. Replace with "diagnosed" or remove if otherwise closed. label Aug 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C: core eol-4.0 Closed because Qubes 4.0 has reached end-of-life (EOL) P: default Priority: default. Default priority for new issues, to be replaced given sufficient information.
Projects
None yet
Milestone
Release 4.0 updates
Development

No branches or pull requests
3 participants
@marmarek @lczerner @andrewdavidwong