Opened 5 years ago
Closed 5 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 5 years ago by jmroot (Joshua Root)
| Owner: | set to MarcusCalhoun-Lopez |
|---|---|
| Status: | new → assigned |
comment:2 follow-up: 3 Changed 5 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 Changed 5 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 5 years ago by FGasper (Felipe Gasper)
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
comment:5 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:6 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
comment:7 follow-up: 9 Changed 5 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 5 years ago by FGasper (Felipe Gasper)
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
I’m reopening because I don’t know if my last comments are being seen.
comment:9 Changed 5 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 follow-up: 11 Changed 5 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 Changed 5 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 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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.
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.