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