When everything is fine, it is fine. If OOM killer shoots down an essential service in one of the Qubes… or one of gazillion virtual disk drives gets full… good luck diagnosing that. We need more watchdogs and self-diagnostics. Today my time sync silently went off because “something” was off in core-tor. Before that, oh, I’ve seen a lot. If we have the least hope for the enterprise – or at least some non-geeks adoption, we need to find and fix all those cases.
1 Like
I thought sys-net was the default ClockVM. So, even when using sys-whonix, shouldn’t time sync be unaffected, since sys-net still runs via clearnet?
Nope, iirc it is recommended to set sys-whonix or core-tor as clock VM. Also it is more about general approach: FR: failure states and diagnostics · Issue #15 · a-barinov/liteqube · GitHub
Where is this recommended, or by whom? If it’s recommended, then why doesn’t the installer or the Whonix Salt recipe do that automatically when installing Whonix (or enabling Whonix when installing Qubes)?
Yes, but this case could illustrate a broader point, namely that if you decide to tweak things too much, your experience will be outside the norm, so you shouldn’t be surprised if you encounter uncommon or unexpected failure modes. Doesn’t mean I disagree with you about needing more watchdogs or self-diagnostics.
It is. swdate works via tor only, so you clockvm should be torified to run it. Same in liteqube – default clock source for htpdate is over tor