iry:
I don’t know how long it will take to get it fixed so here is the workaround:
https://github.com/Whonix/anon-gw-anonymizer-config/pull/9
On the second thought we should be careful with this. If not absolutely
required for Whonix 14, leaving it out. This could introduce some unique
bugs.
First of all, we have to see what upstream thinks about this and how
they go about fixing it. Then if possible and needed, we can add their
fix in Whonix earlier than their fix flows down to Whonix.
I agree. It seems only anon-connection-wizard and swdate is using systemd to start Tor so it is not a big problem I guess:
user@host:~/Whonix/packages$ mygrep -r -i "systemctl.*restart tor"
sdwdate/usr/lib/sdwdate/suspend-post: systemctl --no-pager restart tor@default
anon-connection-wizard/usr/lib/python3/dist-packages/anon_connection_wizard/tor_status.py: command = 'systemctl --no-pager restart tor@default
Great catch!
Thank you so much, Patrick!
From Whonix VirtualBox 14.0.0.6.6 - Testers Wanted! - #15 by TechieMike
Any idea what might cause calling kdesudo without any arguments?
Tried to safeguard against it, but not sure I managed.
https://github.com/Whonix/whonix-setup-wizard/commit/c8a08185f51c71066bb812ecb21ced2563cb39aa
https://github.com/Whonix/whonix-setup-wizard/commit/ba1888405e24d7ad1bb79a1d93329e34fb61ef91
https://github.com/Whonix/whonix-setup-wizard/commit/a1c859ea30d1cc2f0d16795fa183b4b3c5a31f37
user@host:~/Whonix$ mygrep -r -i "command = 'kdesudo"
packages/whonix-repository/usr/lib/whonix-repository/whonix-repository-wizard: command = 'kdesudo %s' % (whonix_repository_wizard)
packages/anon-connection-wizard/usr/lib/anon-connection-wizard/anon-connection-wizard: command = 'kdesudo {}'.format(anon_connection_wizard)
packages/whonix-setup-wizard/usr/lib/whonix-setup-wizard/whonixsetup_check_for_start: command = 'kdesudo {} setup'.format(whonix_setup_wizard)
packages/whonix-setup-wizard/usr/lib/whonix-setup-wizard/whonix-setup-wizard-setup:command = 'kdesudo {} setup'.format(whonix_setup_wizard)
I guess the only possible commands cause this problem are these two:
packages/whonix-repository/usr/lib/whonix-repository/whonix-repository-wizard: command = 'kdesudo %s' % (whonix_repository_wizard)
packages/anon-connection-wizard/usr/lib/anon-connection-wizard/anon-connection-wizard: command = 'kdesudo {}'.format(anon_connection_wizard)
My guess is variables whonix_repository_wizard and/or anon_connection_wizard are not referenced, making the kdesudo called without arguments.
When seeing the code:
whonix_repository_wizard = distutils.spawn.find_executable("whonix-repository-wizard")
if not whonix_repository_wizard == "":
command = 'kdesudo {}'.format(whonix_repository_wizard)
call(command, shell=True)
distutils.spawn.find_executable will return None when executable not found; however, None != "".
distutils.spawn.find_executable should be replaced by shutil.which anyway since the former one is not well-documented and widely used.
I will do some pull requests to fix it.
So no more distutils.spawn.find_executable in Whonix code anywhere? 
Merged.
By the way, I think it would be unreasonable to ask you to do github
pull requests. Not asking for that from anyone else currently either.
Usually it should be enough if you do the git commits. Then I just git
fetch your repository and merge.
Otherwise the more formal approach for third party projects is to create
a new branch based on the source branch (mostly master, some call it
stable or something else), and then create a pull request. Since we’re
familiar here, we can skip such formalities to save time.
On the other hand, github pull requests leave a nice history on github.
So it’s up to you.
(Maybe if we introduce a Whonix14 branch or so or call master only for
Whonix14 or something… Then it may be reasonable to work with
branches. But for now we can keep it simple.)
Minor fix.
https://github.com/Whonix/whonix-repository/commit/77fe16247c47e7e1d4c895294ee3bc996527d842
Sounds good to me. 
Feel free to do the git pull irykoon master if it is more convenient for you.
Sometimes, I need to inform you I did some commits on a repository anyway, so in some cases, I may still use a pull request as a notification that is harder to be missed in the future.
No worry about this. The nice history will neither increase nor decrease my contributions to Whonix.
That’s why I did anyhow. Already. Even less reason to ask you open a github pull request.
Somehow I need to learn about new commits.
It seems the bug will not be fixed very soon by the upstream and I have been using this workaround for a while without any problem.
Do you think it is a good idea to merge it? If not, I can git rm it.
The case that bug will be met if we do not add this workaround may be more common than we previously think:
People restart the Tor with DisableNetwork 1, then they want to use arm which will not be opened since the control port is not opened.
The way tor_status.py check DisableNetwork and enable/disable Tor is out of date:
The better way to do this is using Tor controller:
Since this will be an almost complete rewrite of tor_status.py, I will think more about this and implement and test it with cautious.
Current thought:
systemctl --no-pager restart tor@default (In Whonix, Tor process should always be up and the only difference is connected to the Tor network or not. Correct?)DisbaleNetwork 1 in the files.anon-connection-wizard at boot time as long as Tor is not connecting to the Tor network? (This is not the case currently, btw. And yes, I will fix it if it is not the expected behavious. )