This was resolved thanks to:
2 Likes
access control disabled, clients can connect from any host
That comes from this:
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-sdwdate-gui’
See also below.
I guess don’t fix if not broken. We possibly need to redesign this for wayland anyhow. See also above.
sdwdate-gui wont show up in the taskbar on non-kicksecure-xfce DE like e.g Gnome
Confusing Thing: (Whonix-WS)
Permission Denied because root not used:
user@host:~$ sdwdate --verbose --debug
2022-05-31 17:05:34 - sdwdate - INFO - sdwdate started. PID: 42564
Traceback (most recent call last):
File “/usr/bin/sdwdate”, line 10, in
sdwdate.main()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 1018, in main
global_files()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 970, in global_files
Path(sdwdate_status_files_folder).mkdir(parents=True, exist_ok=True)
File “/usr/lib/python3.9/pathlib.py”, line 1312, in mkdir
self._accessor.mkdir(self, mode)
PermissionError: [Errno 13] Permission denied: ‘/home/user/sdwdate’
user@host:~$
But sdwdate should not run as root:
user@host:~$ sudo sdwdate --verbose --debug
2022-05-31 17:05:18 - sdwdate - INFO - sdwdate started. PID: 42562
2022-05-31 17:05:18 - sdwdate - ERROR - Exit error… sdwdate should not be run as root!
2022-05-31 17:05:18 - sdwdate - INFO - Exiting with exit_code ‘1’ because or reason ‘sdwdate should not be run as root.’.
2022-05-31 17:05:18 - sdwdate - INFO - sdwdate stopped by user or system.
write_status unexpected error: <class ‘NameError’>
2022-05-31 17:05:18 - sdwdate - INFO - sclockadj process not running, ok.
2022-05-31 17:05:18 - sdwdate - INFO - sleep process not running, ok.
Traceback (most recent call last):
File “/usr/bin/sdwdate”, line 10, in
sdwdate.main()
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 1013, in main
exit_handler(exit_code, reason)
File “/usr/lib/python3/dist-packages/sdwdate/sdwdate.py”, line 116, in exit_handler
Path(sleep_long_file_path).unlink(missing_ok=True)
NameError: name ‘sleep_long_file_path’ is not defined
?
1 Like
4 posts were split to a new topic: sdwdate - WARNING - Clock got changed by something other than sdwdate. sleep_time_seconds: 6040 time_delta: 6043 time_passed: -3
1 Like
Clarify more 1/10000 in sdwdate message log.
1 Like
Done in git.
1 Like
Created for it:
1 Like
When using suspend and resume in Qubes-Whonix if too much time passed, Tor circuits will be invalid. This will result in sdwdate failing.
Tor control protocol (“Tor API”) reports everything being okay.
sudo -u sdwdate /usr/libexec/helper-scripts/onion-time-pre-script
__ ### START: ### /usr/libexec/helper-scripts/onion-time-pre-script
__ Status: Subsequent run after boot.
__ Static Time Sanity Check: Within minimum time ‘Fri Feb 18 00:00:00 UTC 2022’ and expiration timestamp ‘Tue May 17 10:00:00 UTC 2033’, ok.
__ Tor circuit: established
__ Tor Consensus Time Sanity Check: Clock within consensus parameters consensus/valid-after 2022-09-11 18:00:00 and consensus/valid-until 2022-09-11 21:00:00.
__ Conclusion: Tor already reports circuit established.
__ ### END: ### Exiting with exit_code ‘0’ indicating ‘success’.
sys-whonix…
tor-prompt
GETINFO status/circuit-established
250-status/circuit-established=1
250 OK
GETINFO status/bootstrap-phase
250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY=“Done”
250 OK
I suspect the information in Tor is actually cached and just returned when asked for. Tor doesn’t actually re-check this information.
Is there any way to force Tor to re-check this using Tor control protocol?
//cc @nyxnor
Read all the GETINFO commands, nothing that I think 100% would work.
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1126
GETINFO network-liveness also does not work.
This project tries to act based on tor logs, but instead of a file, we can use tor-ctrl -w -- SETEVENTS WARN for only relevant events.
But found no command alone that could check if tor is really working.
Because there is also that fact that all streams that are using a circuit that has a failing guard, will still try that guard and fail. And even if all guards are unreacheable, tor does not report that as a boolean, but on logs.
Anyway, asking upstream could be the best.
1 Like
This is the upstream bug report:
The ticket was closed because of this:
So the original issue was ignored and not forwarded elsewhere.
Yeah. A Tor issue reported again here:
Nick Mathewson
@nickm added
Close in favor of Arti
label 2 months ago
So Tor Project won’t fix it. Though, it might be fixed when Arti is released or at least then it could be re-tested and re-reported.
Debian bug report:
broken Tor connection after extended suspend/resume - Tor’s systemd service should restart Tor on resume/thaw after sleep/hibernate
Clicking on sdwdate-gui from the menu will duplicate sdwdate icon in the taskbar/panel. sdwdate-gui need sanity to know that its already running.
1 Like
The Tor network has issues:
This can lead to onions which sdwdate needs having broken connectivity.
If sdwdate cannot change the block after VM boot, then showing the error status is justified. However, if sdwdate fails during a subsequent run (after 60 to 180 minutes randomized) (at time of writing), then showing an error icon in sdwdate-gui technically correct but a usability user because no need to worry the user about it. Clock doesn’t need to be adjusted that often. At least there’s no rationale why it should. Only if sdwdate failed perhaps 1 (or even more) days in a row an error message would be justified.
This behavior should be implemented.