sys-whonix-14 after suspend no longer has a circuit

Issue #2 is sys-whonix-14 after suspend no longer has a circuit apparently, I have to reboot it, is this a known issue, I guess I could change the netvm on anon-whonix and reboot sys-whonix-14 or try to re-bootstrap it, but I’d rather not , as usability is already somewhat an issue with the Tor - Whonix approach

Hi vts

There have been reported issues in the past with pause / suspend / save / hibernate. Most of these are due to issues with time. Namely it is difficult to restore the system clock.

Using pause / suspend / save / hibernate is not recommended. However, if you do use suspend it requires that you manually run TimeSync afterwards.




in whonix-13 I had no issues with after suspending and using sys-whonix

so whonix-14 is Now different , and it is to be expected? and/or one should expect to have to manually run timesync everytime ?

Hi vts

The issue you are having is well documented and the fix applies regardless of which release you are using.

Using pause / suspend / save / hibernate is not recommended for those reasons.

uh, ‘not recommended’ unless one runs sdwgate-dui, and then whonixcheck after every suspend?

or is that not sufficient for some reason?

I was clearly told the timesync issue was a whonix-13, and just hold on and wait till -14 when it would be fixed, maybe that was a different timesync thing, it appeared only this year, prior to that I’ve done 100s of suspend and unsuspend with whonix and never once had an issue (perhaps I’ve been using Whonix-13 insecurely all that time, as I almost never ran whonix checks, and never swdate-gui ) ; or maybe with all the incremental updates, whonixchecks were being done ; either way I feel we are on different wavelengths, bye

We have code for suspend / resume connection restoration and clock fix for Qubes-Whonix.

But there might be a regression in Qubes-Whonix 14 and/or Qubes R4. It’s untested by me since I don’t use suspend / resume and also due to non-Whonix related Qubes issues suspend / resume doesn’t work for me at all.

Why people bother with suspending etc in the first place is the real problem i.e. not willing to change behaviours to increase probability of successful anonymous activity.

This is why we have across the forums, people wanting to also:

  • Install foreign plugins and/or add-ons (making them virtually unique).
  • Run all their activities in the Whonix-GW (one exploit away from complete de-anonymization of all activities etc).
  • And so on.

The problem is not the code not being ready for Qubes-Whonix 14, the problem is user behaviour i.e. they should shut down Tor WS & GW instances before any suspend, and simply restart a new session later on (as well as read more of the documentation).

1 Like

Whatever, when I go to sleep , yes, I suspend my computer, please don’t tell me more users don’t suspend their computers.

Not every User is a sysadmin , if that’s your ‘market’ then fine ; Nor do I really speak coder-ese ; I guess at this stage, I might need to know , is Whonix going to warn me if it works but is “not safe” ?

Or I’ll have to get in the habit of whonixcheck, & swdate-gui after I resume or just go back to straight Torbrowser use instead

Otherwise I’ve always been a Whonix User, it would be my 1st choice, if I am allowed to ask “dumb questions” for the occasional many things I don’t know and probably never will, eg. what ARM is and does etc ; I was happy to get whonix-14 installed really … but I’m not a sysadmin & would like to be welcomed when I ask questions, not immediately told how I must ask , etc etc, ( I see the last message on the board was 2 weeks ago , etc )

The advice is clear.


While Whonix-Workstation is running, if the user selects the pause / suspend / save / resume feature of the virtualizer or the hibernate feature on the host operating system, then manually run TimeSync afterwards! [1]

Start Menu -> Applications -> System -> Time Synchronization Monitor (sdwdate-gui)

It is not recommended to pause / suspend / save / hibernate the Whonix-Gateway, because it is difficult to restore the clock after resume.

Are you using Qubes R3.2 or Qubes R4?

Suspend / resume:

  • Qubes R3.2: Can’t test. -> Unsupported. (I don’t have keyboard access after resume. Qubes R3.2 bug or hardware specific. Bug report not worth it since Qubes R3.2 will be deprecated soon so such a bug has a low chance of getting fixed…)
  • Qubes R4: Works for me.

So this could be a Qubes bug: Qubes fails to dispatch suspend / resume hooks on suspend / resume

I might come up with some instructions how to test for such a Qubes bug so you can report it if applicable.

Meanwhile please read these general chapters:

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]