Suspend, swap, and whonix-gateway performance issues

User Support
1

Hi,

since about a week ago, my whonix gateways start swapping heavily after resuming from suspend. Does anyone have similar issues, and maybe good ways to investigate this?

Thank you!

2

Iā€™ve noticed my sys-whonix become unresponsive after resuming from suspend, have to qvm-kill sys-whonix. Otherwise the next suspend fails.

1 Like
3

I had the same issue and itā€™s also described here:

Fixed it by applying this patch:

3 Likes
4

I also experience the same problem, and itā€™s not just whonix-gw based templates like sys-whonix but also whonix-ws based ones.

Also systemd-socket-proxyd jumps to 100% cpu usage for me after a while and I have to kill it each time. All whonix based templates become unresponsive after suspend and shutting them down makes the Qube Manager unresponsive until it throws an error: I reported the latter on Github: Error when shutting down whonix templates and Qube Manager becomes unresponsive (Failed to shutdown domain '18' with libxenlight) Ā· Issue #7510 Ā· QubesOS/qubes-issues Ā· GitHub

1 Like
5

You can try to change this file in dom0:
/usr/lib/python3.8/site-packages/qubes/vm/qubesvm.py
According to the patch that Iā€™ve linked above and see if itā€™ll fix your issue.

1 Like
6

Thanks, that did solve it for me!

I will see if it also solves the issue with systemd-socket-proxyd jumping to a 100% CPU usage.

Edit: Unfortunately the systemd-socket-proxyd issue is still present.

7

Unfortunately there still is a problem even after applying the latest patch mentioned in: Xen-related performance problems Ā· Issue #7404 Ā· QubesOS/qubes-issues Ā· GitHub

After waking up from suspend, all whonix windows are frozen in this sense: for instance with Tor Browser if I use keyboard shortcuts to move from one tab to another the title of the window changes but thatā€™s about it, nothing else changes, the UI is frozen. I can open applications further but theyā€™re all frozen, they accept and interact with keyboard input but graphically nothing changes aside from the first initial graphical display. And this doesnā€™t apply to whonix only, it also happened with a debian-11 based template but only firefox was affected, and it stayed affected even after restarting it. I donā€™t know what could be the cause behind this or how I can even debug it given that I canā€™t get any graphical update.

8

Does this happen every time after waking up from suspend?

9

It happens to at least one VM everytime, especially disposable whonix-ws ones. Most of the time some VMs are spared while others arenā€™t.

10

Does it affect only browsers or terminals / file managers / etc as well?
When you applied patch at first it didnā€™t happen for some time?

11

Yes, also I noticed that it mostly affected xfce apps and it didnā€™t affect for example the gnome file manager nautilus.

Yes.

12

Maybe youā€™ve updated dom0 and the patched file was overwritten with updated package file without patch?
Did you check if the patch is still there?

1 Like
13

Youā€™re right! That did not cross my mind, thanks a lot for the help! Hopefully no issue will pop up after.

1 Like
14

Unfortunately the issue reappears sometimes with a disposable whonix-ws VM after suspend.

Also sometimes the whonix-gwā€™s CPU usage goes through the roof for no apparent reason and then it goes back to normal.

I made sure this time that the patch wasnā€™t overwritten.

15

It didnā€™t happen for me anymore after applying the patch. Maybe there is some relation to the hardware that can trigger this issue. Or maybe itā€™s a different issue. I think itā€™d be better to reopen the github issue for this.

1 Like
16

@tzwcfq

I think I finally nailed it by finding a way to reliably produce this problem: Open some VMs (not necessarily whonix) then pause them and click on Suspend. After waking up from it the problem that I explained in Suspend, swap, and whonix-gateway performance issues - #7 by resulin appears. Iā€™m interested to see if anyone else can reproduce it. (Note: The earlier patch was enabled)

1 Like
17

Yes, I have the same issue if I pause sys-whonix then enter suspend. When I resume from suspend the paused sys-whonix will be unpaused but partly unresponsive.
I guess itā€™s a bug with resume from suspend procedure that doesnā€™t take into account that some VMs were paused.
I guess you can reopen the github issue with these details.

18

I opened a new issue: Windows become unresponsive for VMs that were paused before suspend Ā· Issue #7548 Ā· QubesOS/qubes-issues Ā· GitHub

1 Like
19

Issue happening inside Qubes-Whonix but root cause is not caused by Qubes-Whonix.

Thank you for attempting and succeeding of reproducing this issue independent of Whonix and Qubes bug reporting!

Also discussed here:

@tlaurion reported:

Commit which introduced the issue:

Which happened in context of:

Commit reported to fix this:

Which also refers to: https://github.com/QubesOS/qubes-issues/issues/7404#issuecomment-1113299850

While weā€™re at itā€¦ More on clocksource tsc vs clocksource xen:

https://phabricator.whonix.org/T389

Not sure thatā€™s a different Qubes bug causing this. Could be the following:

There the symptom was:

systemd-socket-proxyd Failed to get remote socket: Too many open files

4 Likes