Skip to content
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.

Sign up for GitHub

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

Jump to bottom

MULTIPLE DBUS PROBLEM #123

Open
stevebovy opened this issue Apr 28, 2021 · 17 comments
Open

MULTIPLE DBUS PROBLEM #123

stevebovy opened this issue Apr 28, 2021 · 17 comments
Assignees
@spronovo @benhillis
Labels
enhancement New feature or request Missing-Desktop-Dependencies

Comments

@stevebovy
Copy link

stevebovy commented Apr 28, 2021 •
edited

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
@stevebovy stevebovy added the enhancement New feature or request label Apr 28, 2021
@spronovo
Copy link
Collaborator

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

@benhillis
Copy link
Member

Yep it's on the backlog!

@cerebrate
Copy link

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
Copy link
Author

stevebovy commented Apr 29, 2021 •
edited

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

This was referenced May 2, 2021
Open
Open
Open
@UGatgithub
Copy link

UGatgithub commented May 2, 2021 •
edited

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
Copy link

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.

@stevebovy
Copy link
Author

stevebovy commented May 3, 2021 via email

@UGatgithub
Copy link

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
Copy link
Author

stevebovy commented May 4, 2021 via email

@imReker
Copy link

imReker commented May 8, 2021

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

@stevebovy
Copy link
Author

stevebovy commented May 8, 2021 via email

@stevebovy
Copy link
Author

stevebovy commented May 8, 2021 via email

@stevebovy
Copy link
Author

stevebovy commented May 8, 2021 via email

@stevebovy
Copy link
Author

stevebovy commented May 8, 2021 via email

@stevebovy
Copy link
Author

stevebovy commented May 9, 2021 via email

@letrhee letrhee mentioned this issue Jun 10, 2021
Open
@RenatoXSR
Copy link

RenatoXSR commented Jul 29, 2022 •
edited

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
Copy link
Author

stevebovy commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@spronovo spronovo

@benhillis benhillis

Labels
enhancement New feature or request Missing-Desktop-Dependencies
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@cerebrate @imReker @spronovo @stevebovy @benhillis @RenatoXSR @UGatgithub