Re: Programs like pcmanfm, evince, ... don't connect to dbus unless run with dbus-launch

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]

Hi,

dbus is an object-oriented inter-process-communication mechanism.

On a typical single-user system there's one user bus, at least one session
bus and one system bus.

On a typical multi-user system there's multiple user buses, at least as many
session buses and one system bus.

From your messages I suspect that the dbus session bus for your session is not
running.

Try invoking

 echo $DBUS_SESSION_BUS_ADDRESS

.

If it's empty, no session bus is running.

Many many GNOME parts try to use dbus for everything (also arguably for
things which would work perfectly well without dbus, but whatever).

dbus-launch is used to start a message bus from a shell script.

It's usually chained together like this (that's how I use it for real):

$ exec dbus-launch ssh-agent fluxbox

This means that dbus-launch will set up some environment variables,
invoke the daemon and then invoke dbus-daemon and then invoke the
child (here, ssh-agent, passing it "fluxbox"), passing it the environment.

If you invoke "dbus-launch evince" it's starting a mini-session bus
and in there invokes evince.  Evince then cannot connect to the other
services in your session (because there are no other such services in
this mini-session).

I think modifying the slim service to use dbus-launch when starting
the session should have worked just fine.

>> I tried modifying the slim service to launch the session with
> dbus-launch, but that only served to create some new errors when running
> pcmanfm:

Yes, but what does

  echo $DBUS_SESSION_BUS_ADDRESS

say now?

> invoking IsSupported() failed for remote volume monitor with dbus name
                                    ^^^^^^ ???

Also, here, it's not finding lots of service files.  Something needs to make
sure that the dbus daemon finds the service files.  Usually we have an environment
variable for that (see further below).

There are system services in /etc/dbus-1/system-services which should be found in
all cases.

Among those is org.freedesktop.UDisks2 which is not org.gtk.vfs.UDisks2VolumeMonitor .

org.gtk.vfs.UDisks2VolumeMonitor is not in the directory /etc/dbus-1/system-services .

Then there's the ~/.guix-profile/share/dbus-1/services directory.

~/.guix-profile/share is one of the XDG_DATA_DIRS.

dbus-specification.xml specifies that $XDG_DATA_DIRS/dbus-1/services is to be
searched by the user bus.

But this directory only contains files of packages that I personally installed
into my profile - not of the dependencies.  In this case I didn't install the
package of org.gtk.vfs.UDisks2VolumeMonitor - so the service file resides in
/gnu/store/85ih21qjgqcicjkqkw5v96wjvh9hq9g3-gvfs-1.32.1/share/dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.service .

I wonder why it works with the GNOME desktop.  Does it really?

Possible workaround:

youruser$ guix package -i gvfs

Possible fix:

Make nautilus and other Guix packages using gvfs propagate gvfs.

Possible different fix:

Add profile hook which also automatically provides service files of dependencies
without installing the packages into the profile.  I'm not sure how useful that it
since dbus will prefer a running service to service files anyway (I think).  But
at least we would notice a conflict.
Also, is it able to statically determine what these dependencies are?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]