-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MULTIPLE DBUS PROBLEM #123
Comments
@benhillis some good feedback on proper dbus handling on user distro side. |
Yep it's on the backlog! |
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 --
-- 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. |
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 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 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 " & _ This is for an D-ICON Launch:
|
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? |
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 - #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. |
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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB6545QITHB7JL2ATE4TTLVKQPANCNFSM43XYN4SA> . <https://github.com/notifications/beacon/AC2QB66AUZSPNALSC7ATLMLTLVKQPA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGGCTIKA.gif>
|
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. |
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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB65PTJTIC4XOZH5WDCLTL67A7ANCNFSM43XYN4SA> . <https://github.com/notifications/beacon/AC2QB63MWZIQAC3WSQEGTKDTL67A7A5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGGKIIFY.gif>
|
My solution is add |
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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA> . <https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif>
|
--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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA> . <https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif>
|
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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA> . <https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif>
|
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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA> . <https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif>
|
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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB62MZCOKIXOVSJ6ZZCTTMU2AJANCNFSM43XYN4SA> . <https://github.com/notifications/beacon/AC2QB6ZCDOFQQ7XCEEO24MTTMU2AJA5CNFSM43XYN4SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGHFIXFI.gif>
|
I managed to launch some apps that do not show in Windows' Start Menu by launching a terminal window and executing |
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 <#123 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2QB66XTMDIILWKTS45T6LVWPW4DANCNFSM43XYN4SA> .
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
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
The text was updated successfully, but these errors were encountered: