[systemd-devel] default dbus socket path being /run

[Simon McVittie]

On 17/12/13 20:19, Lennart Poettering wrote:
> Hmm, D-Bus and glib both try to be compatible with various older
> systems, so connecting to /var/run appears to be the safe choice.
> 
> That said, I am pretty sure it would be a good idea to patch make them
> avoid /var/run on systems where that's just legacy for /run.

Doing my best to be careful to distinguish between D-Bus, a protocol,
and dbus, an implementation, in this mail...

dbus (the reference implementation of D-Bus) uses the ${localstatedir}
defined by the GNU coding standards. Conventional distributions (for a
very broad definition of "conventional" that includes Linux, *BSD, Hurd,
etc.) are expected to set that to its FHS location (/var/run), resulting
in /var/run/dbus/system_bus_socket. Unconventional distributors are
responsible for their own OS integration, and if they break it, they get
to keep both pieces.

The dbus upstream default is not going to change in ways that would
break existing systems. If someone wants to contribute a patch that
decouples the default listening and connecting addresses, and set the
default listening address to be in ${localstatedir} but the default
connecting address to something like the expansion of
"unix:/run/...;unix:/var/run/...;unix:${localstatedir}/..." (or possibly
try ${localstatedir} earlier), then I'd be happy to review it; see dbus
commits 723da235, b5d36dc2, 05b0b9e6 for relevant context.

I don't consider "I have both /var/run and /run, but they are not
synonymous" to be a supported configuration for either D-Bus or dbus. As
far as I'm is concerned, systems should either be FHS (consistently
/var/run), or preferably, "like modern Linux" (one of {/var/run,/run} is
a symlink or bind-mount pointing to the other).

If systemd doesn't support the former, but only the latter, that's also
fine - systemd is not obliged to support everything that dbus does (but
dbus has always supported the former, so it should continue to do so).

Similarly, I think it would be appropriate for a GLib maintainer to make
it try to connect to sockets in /run, /var/run and its ${localstatedir}
(in some order) when asked to connect to the system bus, but I think it
would be incorrect to make newer GLib versions stop working on existing
systems that only have /var/run.

    S