When I type "sudo compiz" the final warning/error message is...

[Verld]

WARN 2017-07-04 09:07:31 unity :0 Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
I am using VCXSrv on Windows 10 Home on a Dell Inspiron 1545. Yes, I do know that product is not tested for Windows 10 upgrade.

[sunjoong]

@Verld - You look like to have posted https://superuser.com/questions/1225588/when-i-run-sudo-compiz-on-windows-subsystem-for-linux also :) By the way, I searched and found #637 seems similar to this issue.

[benhillis]

@Verld - Thank for posting. Could you please fill out our issue template so we have enough information to debug this?

[therealkenc]

so we have enough information to debug this

It's just dbus not running. [dbus has been working more-or-less since #376]

[therealkenc]

It looks like something has in fact changed recently, for some value of 'recent' in xenial-update temporal units. Auto-launch of the dbus session daemon appears broken in some scenarios. I haven't tried compiz (because running compiz makes me sad), but this is showing up when running another large popular out of scope body of software. [Previous to some random apt upgrade dbus was being auto-launched.]

Anyway, I am fairly certain the problem with dbus auto-launch is not with WSL (the kernel layer). So Sunil is probably safe for now. The problem, at base, is that the dbus session isn't supposed to be auto-launched in the first place; in Real Linux you've got a Real Desktop Session that was started via systemd, lightdm and friends. This warning would show up in Real Linux under the same circumstances.

But if you want to have your dbus ducks in a row on WSL, the following should work.

# you are going to need a DISPLAY
export DISPLAY=localhost:0
# you don't have an accessibility bridge
export NO_AT_BRIDGE=1
# launch a text dbus session
exec dbus-run-session -- bash
# you probably want a system dbus too 
sudo service dbus start
# finally, launch a program that thinks it should be living in a desktop session
...

[therealkenc]

I haven't seen the dbus auto-launch problem in a while. Per previous post there's no indication of a syscall behaviour gap related to dbus; and no repro was given. Since this is compiz related, the best hang-out for continued discussion would be #637.

[Verld]

I think I stumbled onto something. I have to use gnomesu or something instead of sudo.