Solved dbus insidious tentacles

M

mer

Some of the ports of Linux software are incredibly invasive. Ran into an interesting one today.
My FreeBSD box, I use Windowmaker or awesome with Xorg, so minimal. Don't run dbus-launch in my .xinitrc.

I have a Linux Ubuntu laptop (for $WORK) that I ssh into, forward X back to FreeBSD for development/testing work.

Had rebooted both, ssh'd into Linux, then tried running emacs. Nothing showed up locally. Tried another program same thing.
processes running, but not displaying.

Started firefox on my FreeBSD system, which automatically launches dbus.
The applications forwarding from Linux magically appear now.

Simpler applications like old fashioned xterm worked fine displaying back, but anything associated with a more "desktop" or Gnome thing seem to need dbus running on the local machine to display.

No problem that I'm looking to solve, just pointing out a weird interaction in case anyone else runs into it.
 
Why would it require a local DBUS? With remote X the application runs on the remote machine. All you get is the X11 protocol on your 'client' machine.
 
SirDice said:
Why would it require a local DBUS? With remote X the application runs on the remote machine. All you get is the X11 protocol on your 'client' machine.
Click to expand...
I know that is what I found confusing. "simple" x applications like good old xterm worked fine. I've been running these systems in this configuration for a long time worked just fine. But since my BSD desktop is a daily driver, starting firefox to say come here is a typical first thing before ssh over to the other machine. I've got a few things I want to look at. I think the dbus session that is launched by firefox hangs around even after exit so I'm going to check that, if it does kill the dbus stuff on my local machine and retry the applications.
 
I think it was a comedy of errors. I had rebooted both systems, had not actually logged in on the laptop which would have started dbus on the remote system I ssh into.
 
Its weird I find it the other way.

If a "dbus-enabled" program is running on my remote machine, if I try to X11/ssh forward another instance. It just tells the remote machine to spawn another local instance. Obviously this means that it uses the local (DISPLAY=:0) rather than my X11 forwarded one.

These Linux technologies really target desktop use-cases rather than anything remotely "unixy".
 
  • Like
Reactions: mer
Finally had a chance to try killing dbus things on the remote machine and then run over the forwarded X connection and was able to reproduce my original problem. So it was not local dbus, it was remote dbus not running.
 
Not related to your problem with remote dbus, just sharing my pains here:
I wanted to get rid of dbus on my laptop and I found that my login manager slim requires dbus enabled during startup. I would love to compile it without dbus option, but I got stuck on the compilation itself. But the bigger problem I found is actually the Firefox itself. The idea of compiling it every time it gets released is like a nightmare to me. And then I guess Thunderbird would spawn dbus as well. I remember one time when I managed to disable system-wide dbus and still log into my WM, Firefox spawned dbus locally, but at least not as root.
 
  • Like
Reactions: mer
Thanks for all the help/words of wisdom. It was truly just a timing thing that I had rebooted both machines, logged into the BSD, ssh'd to the Linux (which I had not logged into) from a terminal on the BSD machine, then tried to spawn an emacs which on the Linux box is "emacs-gtk" so the gtk portion must be looking for dbus stuff because it's too hard to simply read a config file and "what if I don't match the user theme in the DE".

As for firefox on the BSD box, I have simply mv /usr/local/bin/dbus* /usr/local/bin/dbus*.BAD and firefox from pkgs runs just fine. There may be some configuration things or lookups that don't happen but it works.

Let me go mark this Solved before Graham sees it ;)
 
You must log in or register to reply here.
Back
Top