Suspend, swap, and whonix-gateway performance issues


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!

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

I had the same issue and it’s also described here:

Fixed it by applying this patch:


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

You can try to change this file in dom0:
According to the patch that I’ve linked above and see if it’ll fix your issue.

1 Like

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.

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.

Does this happen every time after waking up from suspend?

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.

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?

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


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

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