MULTIPLE DBUS PROBLEM

[stevebovy]

trafficstars

Is your feature request related to a problem? Please describe.

THANKS FOR WSLG !

BUT, A problem with many puzzle pieces needs a multi-pronged solution. You have done very well with the x-window puzzle piece, and I thank you for your excellent work, but you have not yet addressed the IPC-DBUS puzzle piece which I will try to describe as follows:

THE PARENT INIT PROCESS AND SHARED DBUS INSTANCE PROBLEM

DBUS is designed to create “ONE shared instance” for all desktop apps launched from the desktop session which is the centralized parent of all subsequent apps. This is done with environment variables that are created. These variables (contain info for the DBUS-IPC mechanism) and are intended to be “inherited” by the child GUI processes.

If you independently launch individual gnome GUI apps without the proper pre-configured shared DBUS desktop instance via the INHERITED VARIABLES, then they will automatically create their own private DBUS instance . Thus you could end up with many MULTIPLES OF UNNECESSARY DBUS instances.

Describe the solution you'd like

WSL and/or WSL2 NEEDS configuration support for a PARENT INIT process that can run INIT scripts from which all subsequent child processes inherit their configuration variables.

Could we make this NEW wslg BLACK-BOX the new init process and solve two birds with one stone ?

Obviously this INIT PROBLEM has been around for a looonnnggg time , and the scope of the problem is relevant way beyond the simple reach of GUI APPS THAT USE DBUS

Additional context

A comprehensive and thorough GUI solution must address ancillary side issues like DBUS

[spronovo]

@benhillis some good feedback on proper dbus handling on user distro side.

[benhillis]

Yep it's on the backlog!

[cerebrate]

This is something I have been wondering about myself. I had previously (when using a Windows-side X server) solved the dbus problem to my own satisfaction with my systemd-genie, which provides both system and session dbuses that everything seems happy to use, and as far as I can tell under WSLg this continues to be the case.

But then I notice that there is a system dbus in the WSLg system distro --

root@pallas [ /mnt/c/ProgramData/WSL-Kernel ]# dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/
freedesktop/DBus org.freedesktop.DBus.ListNames
method return time=1619661719.593187 sender=org.freedesktop.DBus -> destination=:1.17 serial=3 reply_serial=2
   array [
      string "org.freedesktop.DBus"
      string ":1.17"
   ]

-- and I wonder to myself, what does that do, and how concerned about that service do I need to be? 😀

On another note, I'd also like to pre-register a little concern about prospective dbus handling solutions and that they not break existing/customized dbus solutions that we may already be using. Or at least can be turned off such that they won't, preferably without affecting the rest of WSLg.

[stevebovy]

I have a vbscript called gterm.vbs.

I use it to launch my g-term from a right-click or from a d-icon. I have also incorporated many other options and features.

I created this script while researching how-to do wsl-gui with xwin.

My script detects xwin and auto-launches it if necessary and then goes on to invoke which-ever command the context of the script dictates.

Dbus was one of the issues that cropped out of this research.

Here is a vbscript variable I use in my script to handle dbus:

setdbus = " if [ -z ""$(pidof dbus-daemon)"" ]; then " & _ "dbus-launch --sh-syntax > /tmp/save-dbus " & _ "; fi; . /tmp/save-dbus; "

This is for an D-ICON Launch:

objShell.Run strBashCmd & " ""cd ~;" & setexports & setdbus _ 
  & LaunchTarget & """", 0, False

[UGatgithub]

As I understand this, there is a Parent (Linux desktop session) to Child (Linux apps) DBUS dependency that wslg does not take care about yet which needs to get solved to become able to run a (more or less) full blown desktop session (e.g. Ubuntu gnome-session) under wslg without an additional Xserver / client setup, correct?

[cerebrate]

I think it's a bit more complicated than that. I'm posting the details of my assorted WSLg learnings in a discussion thread I've created over here - https://github.com/microsoft/wslg/discussions/144 - to try to avoid polluting the issues too much, and I'll have some notes on dbus up there in about an hour from now.

[stevebovy]

The problem is that various Desktop apps use an IPC system that requires a root-init process to init the inherited environment.

Gnom apps use dbus. The concept of a desktop-session may or may not be have anything to do with dbus itself.

Dbus was intended and designed to be used within the framework of a singular starting point referred to as a desktop session.

Within this framework it gets executed once and all apps utilize it in some type of shared fashion.

The problem arises in wslg on xwin when you take the noodles out of the soup, (i.e. take the app out of the desktop).

When you execute a gnome app in wsl there in no support for a singular starting point (init process). Therefore every time a gnome app

Starts he thinks he is the first-guy and must create a new dbus session. Thus you end up with multiple dbus instances.

From: Uwe G. @.*** Sent: Sunday, May 2, 2021 6:54 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

As I understand this, there is a Parent (Linux desktop session) to Child (Linux apps) DBUS dependency that wslg does not take care about yet which needs to get solved to become able to run a (more or less) full blown desktop session (e.g. Ubuntu gnome) under wslg without an additional Xserver / client setup, correct?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-830813224 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB6545QITHB7JL2ATE4TTLVKQPANCNFSM43XYN4SA . https://github.com/notifications/beacon/AC2QB66AUZSPNALSC7ATLMLTLVKQPA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGGCTIKA.gif

[UGatgithub]

So for gnome on wsl there is no Parent (init process) to Child (dbus session) dependency which on the other hand allows the Linux apps to float independently around in Bill’s Windows soup. They just can‘t float in a Xwin soup within Bill‘s soup without knowing (enough) about their own origin, meaning they can‘t connect themselves to one and the same dbus frame in the overall mixed desktop framework, so each of the gnome child’s creates his own „parent“ dbus session, like a frame for itself but not for others. But how do gnome apps in Linux identify and get connected to the single starting point (init process) to avoid the same childish thing happens there? I wouldn’t think it is the init process that calls them to let them know, „Here I am - you can utilize me!“, my understanding would be that gnome apps check for a kind of unique identifier of the init process or similar, or?

[stevebovy]

The dbus man pages explain some of this. And I have already discussed this within the context of this issue.

When you do dbus-launch to create the dbsu “session” dbus exports “variables” that have info about how to connect to the dbus PIPes that support the

Ipc communication mechanism.

This is done In the init process so that all subsequent child processes will be able to access and read those variables. The gnome apps are coded to look for these

Variables, when they find them they connect to the already created and existing dbus-daemon. If they do not find them then they create a new private dbus-daemon for their own usage.

From: Uwe G. @.*** Sent: Tuesday, May 4, 2021 2:47 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

So for gnome on wsl there is no Parent (init process) to Child (dbus session) dependency which on the other hand allows the Linux apps to float independently around in Bill’s Windows soup. They just can‘t float in a Xwin soup within Bill‘s soup without knowing (enough) about their own origin, meaning they can‘t connect themselves to one and the same dbus frame in the overall mixed desktop framework, so each of the gnome child’s creates his own „parent“ dbus session, like a frame for itself but not for others. But how do gnome apps in Linux identify and get connected to the single starting point (init process) to avoid the same childish thing happens there? I wouldn’t think it is the init process that calls them to let them know, „Here I am - you can utilize me!“, my understanding would be that gnome apps check for a kind of unique identifier of the init process or similar, or?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-831816727 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB65PTJTIC4XOZH5WDCLTL67A7ANCNFSM43XYN4SA . https://github.com/notifications/beacon/AC2QB63MWZIQAC3WSQEGTKDTL67A7A5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGGKIIFY.gif

[imReker]

My solution is add export $(dbus-launch --autolaunch=dcc0096fea724a74e0427e485f435814 --exit-with-x11) to /etc/bash.bashrc

[stevebovy]

Thanks,

So what does auto-launch with the weird identifier accomplish, and how does it eliminate multiple duplicate dbus-daemons ???

From: Reker @.*** Sent: Saturday, May 8, 2021 6:12 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

My solution is add export $(dbus-launch --autolaunch=dcc0096fea724a74e0427e485f435814 --exit-with-x11) to /etc/bash.bashrc

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-835357589 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA . https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif

[stevebovy]

--autolaunch

This option implies that “dbus-launch” should scan for a

previously-started session and reuse the values found there. If no

session is found, it will start a new session.

I would like to know how dbus “ scans for a previous started session” because I have never seen it succeed in re-using a previous session ,

It always ends up starting a new session. IF WE CAN FIGURE OUT HOW TO GET DBUS TO RE-USE EXISTING SESSION WE COULD SOLVE THIS ISSUE

AND PUT IT TO REST :) !!!!

Also you might want to use $(dbus-uuidgen –get) to fetch the machine-id

From: Reker @.*** Sent: Saturday, May 8, 2021 6:12 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

My solution is add export $(dbus-launch --autolaunch=dcc0096fea724a74e0427e485f435814 --exit-with-x11) to /etc/bash.bashrc

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-835357589 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA . https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif

[stevebovy]

Thanks,

I want a solution that does not require any changes manual or otherwise to profile or .bashrc

All my linux gui set-up is contained within the windows script which launches the gui app ( no internal linux files should be modified)*

*(except for configuration changes to make things work better)

From: Reker @.*** Sent: Saturday, May 8, 2021 6:12 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

My solution is add export $(dbus-launch --autolaunch=dcc0096fea724a74e0427e485f435814 --exit-with-x11) to /etc/bash.bashrc

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-835357589 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA . https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif

[stevebovy]

According to the dbus-tutorial:

When using D-Bus with a message bus daemon, libdbus automatically discovers the address of the per-session bus daemon by reading an environment variable. It discovers the systemwide bus daemon by checking a well-known UNIX domain socket path (though you can override this address with an environment variable).

SO WE NEED TO FIND A WAY TO CHANGE DBUS SO IT LOCATES THE EXISTING “PER-SESSION” WITHOUT USING AN ENVIRONEMTN VARIABLE.

From: Reker @.*** Sent: Saturday, May 8, 2021 6:12 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

My solution is add export $(dbus-launch --autolaunch=dcc0096fea724a74e0427e485f435814 --exit-with-x11) to /etc/bash.bashrc

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-835357589 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA . https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif

[stevebovy]

There are two parts to this issue

1.  How to get  the session dbus started  one and only one time
   

2.  How to communicate the dbus-address
   

There are many different ways to address the first issue.

On the second issue, a careful reading of the dbus-daemon docs, indicates that you can pre-configure a “well-known” dbus-address, and then

Manually pre-set the dbus-address environment variable to that same value. When you pre-set the variable, the gnome apps will not auto-launch dbus.

From: Reker @.*** Sent: Saturday, May 8, 2021 6:12 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

My solution is add export $(dbus-launch --autolaunch=dcc0096fea724a74e0427e485f435814 --exit-with-x11) to /etc/bash.bashrc

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-835357589 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA . https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif

[RenatoXSR]

I managed to launch some apps that do not show in Windows' Start Menu by launching a terminal window and executing eval $(dbus-launch --sh-syntax) before running the desired app, as suggested on https://x410.dev/cookbook/wsl/sharing-dbus-among-wsl2-consoles/

[stevebovy]

Yes and each time you do this you will get a duplicate copy/instance of dbus :)

From: Renato Rosa @.*** Sent: Friday, July 29, 2022 8:01 AM To: microsoft/wslg @.> Cc: stevebovy @.>; Author @.***> Subject: Re: [microsoft/wslg] MULTIPLE DBUS PROBLEM (#123)

I manage to launch some apps that do not show in Windows' Start Menu by launching a terminal window and executing eval $(dbus-launch --sh-syntax) as suggested on https://x410.dev/cookbook/wsl/sharing-dbus-among-wsl2-consoles/

— Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/123#issuecomment-1199472875 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2QB66XTMDIILWKTS45T6LVWPW4DANCNFSM43XYN4SA . You are receiving this because you authored the thread.Message ID: @.***>

[stevebovy]

It is now 2024, and upon revisiting this issue, I wish to complement both ubuntu and wsl for their efforts to address this issue.

BUT, after re-examining the state of this issue I have discovered a new question:

When I start a BRAND NEW vm ubunto session I discover the following which looks on the surface to be excellent:

bovy@DEVDESKSJB:~$ ps -ael | grep dbus 4 S 102 259 1 1 80 0 - 2193 - ? 00:00:00 dbus-daemon 0 S 1000 493 426 0 80 0 - 2075 - ? 00:00:00 dbus-daemon bovy@DEVDESKSJB:~$

bovy@DEVDESKSJB:~$ set | grep DBUS DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus bovy@DEVDESKSJB:~$

bovy@DEVDESKSJB:~$ ls -al /run/user/ total 0 drwxr-xr-x 3 root root 60 Sep 10 13:15 . drwxr-xr-x 20 root root 580 Sep 10 13:15 .. drwxr-xr-x 6 bovy bovy 260 Sep 10 13:15 1000 bovy@DEVDESKSJB:~$

bovy@DEVDESKSJB:~$ ls -al /run/user/1000 total 0 drwxr-xr-x 6 bovy bovy 260 Sep 10 13:15 . drwxr-xr-x 3 root root 60 Sep 10 13:15 .. srw-rw-rw- 1 bovy bovy 0 Sep 10 13:15 bus drwxr-xr-x 4 bovy bovy 80 Sep 10 13:15 dbus-1 drwx------ 2 bovy bovy 140 Sep 10 13:15 gnupg srw-rw-rw- 1 bovy bovy 0 Sep 10 13:15 pipewire-0 -rw-rw---- 1 bovy bovy 0 Sep 10 13:15 pipewire-0.lock srw-rw-rw- 1 bovy bovy 0 Sep 10 13:15 pk-debconf-socket drwx------ 2 bovy bovy 80 Sep 10 13:15 pulse srw-rw-rw- 1 bovy bovy 0 Sep 10 13:15 snapd-session-agent.socket drwxr-xr-x 5 bovy bovy 140 Sep 10 13:15 systemd lrwxrwxrwx 1 root root 31 Sep 10 13:15 wayland-0 -> /mnt/wslg/runtime-dir/wayland-0 lrwxrwxrwx 1 root root 36 Sep 10 13:15 wayland-0.lock -> /mnt/wslg/runtime-dir/wayland-0.lock bovy@DEVDESKSJB:~$

bovy@DEVDESKSJB:~$ ls -al /run/user/1000/bus srw-rw-rw- 1 bovy bovy 0 Sep 10 13:15 /run/user/1000/bus bovy@DEVDESKSJB:~$

bovy@DEVDESKSJB:~$ ls -al /run/user/1000/dbus-1 total 0 drwxr-xr-x 4 bovy bovy 80 Sep 10 13:15 . drwxr-xr-x 6 bovy bovy 260 Sep 10 13:15 .. drwxr-xr-x 2 bovy bovy 40 Sep 10 13:15 service drwx------ 2 bovy bovy 40 Sep 10 13:15 services

BUT:

After I start a gnome-terminal, an additional unnecessary dbus daemon is started:

bovy@DEVDESKSJB:~$ gnome-terminal & [1] 1475

bovy@DEVDESKSJB:~$ ps -ael | grep dbus 4 S 102 259 1 0 80 0 - 2193 - ? 00:00:00 dbus-daemon 0 S 1000 493 426 0 80 0 - 2144 - ? 00:00:00 dbus-daemon 0 S 1000 1504 1498 0 80 0 - 2075 - ? 00:00:00 dbus-daemon

bovy@DEVDESKSJB:~$

I do not understand why or how this is happening, Or how it can be FIXED