dbus should install system socket into standard path

[FGasper (Felipe Gasper)]

The dbus port installs its system socket to /opt/local/var/run/dbus/system_bus_socket. This is a nonstandard location that no client library other than libdbus will know to use.

Should it not should use the standard path? (/var/run/dbus/system_bus_socket)

Thank you!

[jmroot (Joshua Root)]

As a general rule we keep all files inside $prefix to avoid conflicts with future OS updates, other package managers, and manually installed software. I admit I'm not familiar enough with dbus conventions to say if this should be an exception.

[FGasper (Felipe Gasper)]

libdbus doesn’t provide a way to query for the compile-time configuration, so the deviation from the standard path leaves other implementations without a reliable means of connecting.

The D-Bus specification says:

The address of the system message bus is given in the DBUS_SYSTEM_BUS_ADDRESS environment variable. If that variable is not set, applications should try to connect to the well-known address unix:path=/var/run/dbus/system_bus_socket.

Is it possible that the DBUS_SYSTEM_BUS_ADDRESS environment variable could be set, similar to how DBUS_LAUNCHD_SESSION_BUS_SOCKET is set currently?

[ryandesign (Ryan Carsten Schmidt)]

Replying to FGasper:

Is it possible that the DBUS_SYSTEM_BUS_ADDRESS environment variable could be set,

When?

similar to how DBUS_LAUNCHD_SESSION_BUS_SOCKET is set currently?

How and when is that currently set?

[FGasper (Felipe Gasper)]

#28271

Going by the above, it appears to be set in launchd.

/opt/local/etc/LaunchAgents/org.freedesktop.dbus-session/org.freedesktop.dbus-session.plist

This appears to be the source?

It’s notable also that /opt/local/bin/gdbus is broken currently, assumedly as a result of this issue:

  > /opt/local/bin/gdbus monitor --system --dest org.freedesktop.DBus
  Error connecting: Could not connect: No such file or directory

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In aa9089b3a2d5e0a54ad446d71f53467cec9687c6/macports-ports (master):

glib2: search for dbus socket in correct location

Fixes #57784

[ryandesign (Ryan Carsten Schmidt)]

In fe6f11c71a3db9c882a9515e0a563572f98514f9/macports-ports (master):

glib2-devel: Search for dbus socket in correct location

See: #57784

[FGasper (Felipe Gasper)]

This does not fix the problem; it only puts a band-aid on for glib.

The problem is that a standard D-Bus client has no way of discovering the system socket.

Can the DBUS_SYSTEM_BUS_ADDRESS variable not be set?

[FGasper (Felipe Gasper)]

I’m reopening because I don’t know if my last comments are being seen.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to FGasper:

This does not fix the problem; it only puts a band-aid on for glib.

The problem is that a standard D-Bus client has no way of discovering the system socket.

Can the DBUS_SYSTEM_BUS_ADDRESS variable not be set?

I am a little unclear on what you are suggesting.
It seems to me that we have to address this issue on a port by port basis.
If, with more than one data point (glib), we can attempt to come up with a more elegant solution.
Is there another port that is not working correctly?

Setting a global variable for all users at all times seems to be antithetical to how we usually do things.
Forgive me if I am missing something.

[FGasper (Felipe Gasper)]

D-Bus defines specific environment variables that clients are to check for socket locations. One of them is the DBUS_LAUNCHD_SESSION_BUS_SOCKET, which gives the login session bus’s socket location. MacPorts already sets this variable; for me right now it looks thus:

> env | grep DBUS
DBUS_LAUNCHD_SESSION_BUS_SOCKET=/private/tmp/com.apple.launchd.5vFebZKcfj/unix_domain_listener

Another such environment variable is DBUS_SYSTEM_BUS_ADDRESS, but MacPorts doesn’t set that one. If that were changed, then all standard D-Bus clients--not just glib--would interoperate correctly with MacPorts’s D-Bus.

Does that make more sense?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to FGasper:

Does that make more sense?

Thank you for going into more detail, but I am not sure how this could be easily accomplished.

If we consider /Library/LaunchAgents/org.freedesktop.dbus-session.plist,
DBUS_LAUNCHD_SESSION_BUS_SOCKET is set because it uses SecureSocketWithKey, so "a securely generated socket is created".

If the path is know (and not created), then I believe SockPathName is supposed to be used, but no environmental variable is set.

There is an XML property EnvironmentVariables, but I do not believe it only sets the value for the process to be run.

Do you have any suggestions on how DBUS_SYSTEM_BUS_ADDRESS could be set?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I will close this ticket since there does not yet seem to be a proposal for a general fix and since the immediate problem (glib) has been fixed.
If a more elegant solution is found, we can revisit the issue and reopen the ticket.

Thank you for the report and sorry we have not yet fully addressed your concerns.