[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

[msgdispatcher] bug: "$delete_wrapper"

I am experiencing the following problem with Whonix 15 (buster-proposed-updates repo enabled), specifically with whonix-ws template. Everytime I start a VM based on it, the following message appears.

###############################################################################
msgdispatcher script bug.
No panic. Nothing is broken. Just some rare condition has been hit.
Try again later. There is likely a solution for this problem.
Please see Whonix News, Whonix Blog and Whonix User Help Forum.
Please report this bug!
who_ami: user
msgdispatcher_identifier: whonixcheck
error_text: sudo --non-interactive msgdisptacher_username="$msgdisptacher_username" msgdispatcher_identifier="$msgdispatcher_identifier" msgdispatcher_appendix=“messagex_done” “$delete_wrapper”
last exit_code: 1
###############################################################################

I run tasket’s Qubes-VM-Hardening script v 0.9.3. Disabling vm-boot-protect does not change the situation.

Cheers.

1 Like

Improved error handler just now to ease debugging this.

If you like to debug this, please replace the existing script /usr/lib/msgcollector/msgdispatcher with the newer script.

https://github.com/Whonix/msgcollector/blob/master/usr/lib/msgcollector/msgdispatcher

(Press “raw”.)

That would provider better debug output.

Please also run the following command and post the output here:

sudo find /var/run/msgcollector

Another enhancment which makes this easier to debug but not the solution yet.

This is now also in buster-proposed-updates repo.

Ok, thanks for your answer.
I updated msgcollector and the message error when I start a whonix-ws based VM is:

###############################################################################
msgdispatcher script bug.
No panic. Nothing is broken. Just some rare condition has been hit.
Try again later. There is likely a solution for this problem.
Please see Whonix News, Whonix Blog and Whonix User Help Forum.
Please report this bug!
who_ami: user
msgdisptacher_username: whonixcheck
msgdispatcher_identifier: whonixcheck
msgdispatcher_appendix:
delete_wrapper: /usr/lib/msgcollector/msgdispatcher_delete_wrapper
error_text: sudo --non-interactive msgdisptacher_username="$msgdisptacher_username" msgdispatcher_identifier="$msgdispatcher_identifier" msgdispatcher_appendix=“messagex_done” “$delete_wrapper”
last exit_code: 1
#######################################################

and

sudo find /var/run/msgcollector
/var/run/msgcollector
/var/run/msgcollector/user
/var/run/msgcollector/user/msgdispatcher_x_subshell_fifo
/var/run/msgcollector/user/msgdispatcher_pidx
/var/run/msgcollector/user/msgdispatcher_x_lock
/var/run/msgcollector/whonixcheck
/var/run/msgcollector/whonixcheck/whonixcheck_messagecli_done
/var/run/msgcollector/whonixcheck/whonixcheck_messagex_done
/var/run/msgcollector/whonixcheck/whonixcheck_lefttop
/var/run/msgcollector/whonixcheck/whonixcheck_titlex
/var/run/msgcollector/whonixcheck/whonixcheck_parenttty
/var/run/msgcollector/whonixcheck/whonixcheck_typex
/var/run/msgcollector/whonixcheck/whonixcheck_icon
/var/run/msgcollector/init_done

Just for the record: I tried to change the template for these VMs with a whonix-ws-15 where tasket’s VM-hardening script is not installed. In this case, no problems detected when a VM is started.

Thanks for your help.

1 Like

I got the identical error message… but none of my Whonix 15 templates currently have Qubes-VM-hardening installed.

And the error is not very repeatable.

At first glance, the main variables may be startup timing (race condition?) and the fact that qubes-rpc VMAuth is set to “ask” in dom0, as per the qvmh installation procedure. (I am getting VMAuth popups for sys-whonix when starting a terminal or browser for a whonix-ws based appvm, but not when starting a terminal in the whonix-ws template.)

Also, I recall using Whonix about a month ago and didn’t experience these issues.

I would prefer addressing the issues sans qvmh before troubleshooting with qvmh, but I’ll try installing it in a whonix-ws-15 clone for now to see if the error message becomes more predictable, VMAuth prompts are affected, etc.

1 Like

Installing qvmh makes the error occur consistently. But I already see a probable cause in the error message: “msgdispatcher_identifier: whonixcheck error_text: sudo…”

Its my understanding that ‘sudo’ should not be used in system or application scripts bc its a user invocation tool. The appropriate command for switching users in scripts would be ‘su’ (both qvmh and Qubes-VPN-Support have examples of displaying user messages via ‘su’); also note its generally only workable when invoking it as root to switch to a less privileged user.

Even if this weren’t the case, scripting with sudo doesn’t appear to be compatible with this type of “vm-sudo” Qubes configuration (even though it seems fine with the permissive Qubes default config for obvious reasons).

1 Like

We actually limited su for security as per:

msgdispatcher should not cause any sudoers prompt. If it does, it would require fixing its /etc/sudoers.d/ exception file. Can you try without Qubes-VM-hardening and sudo requirement only?

Also good to change exit code of delete wrapper to know if delete wrapper or sudo is failing.

sudo has a switch --noninteractive. Using this a lot in Whonix. Works great.

“sudo should not be used non-interactive”: citation required.

Right, the VMAuth prompts come from sys-whonix, and this seems to be the result of an appvm connecting or disconnecting with the sys-whonix proxyvm. So maybe no direct relation to what whonix-ws is doing (although that is an issue in itself).

Re: su vs sudo in scripts… It may not matter here if you are always running sudo as root or have a sudoers.d config as you indicated. But su appears to be the convention as its usually a core command in Linux distros, while sudo may be optional on some (such as fedora). Never saw sudo in init.d/cron scripts for example, and the sudo --non-interactive option was added relatively recently in 2011. I think Qubes scripts only use su. But I digress…

I didn’t activate the vm-boot-protect* service after installing it, so my prediction is that it will behave the same when only sudo is reconfigured. I’ll have to test a bit more to be sure.

2 Likes

Removing user user from group sudo will break /etc/sudoers.d/msgcollector

Described here:

Update: I’m continuing to experience this msgdispatcher error with unmodified templates. The last time was today when sys-whonix displayed it when beginning template updates (sys-whonix had just started). However, the system was under a bit of stress as it was also updating dom0 and playing music at the same time.

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