Opened 6 years ago

Closed 6 years ago

#57784 closed defect (fixed)

dbus should install system socket into standard path

Reported by: FGasper (Felipe Gasper) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.5.4
Keywords: Cc:
Port: dbus

Description

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!

Change History (12)

comment:1 Changed 6 years ago by jmroot (Joshua Root)

Owner: set to MarcusCalhoun-Lopez
Status: newassigned

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.

comment:2 Changed 6 years ago by 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?

comment:3 in reply to:  2 Changed 6 years ago by 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?

comment:4 Changed 6 years ago by 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
Last edited 6 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:5 Changed 6 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: assignedclosed

In aa9089b3a2d5e0a54ad446d71f53467cec9687c6/macports-ports (master):

glib2: search for dbus socket in correct location

Fixes #57784

comment:6 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

In fe6f11c71a3db9c882a9515e0a563572f98514f9/macports-ports (master):

glib2-devel: Search for dbus socket in correct location

See: #57784

comment:7 Changed 6 years ago by 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?

comment:8 Changed 6 years ago by FGasper (Felipe Gasper)

Resolution: fixed
Status: closedreopened

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

comment:9 in reply to:  7 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by 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?

comment:11 in reply to:  10 Changed 6 years ago by 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?

comment:12 Changed 6 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.