Apparently this matters, but I can't figure out why.
With 1.12.0 here, if I pass the following configure flags:
  --with-system-pid-file=/run/dbus/dbus.pid \
  --with-system-socket=/run/dbus/system_bus_socket \
with /run and /var/run being *separate* then I have a wonky system with e.g. Xfce taking quite some time to start and several <defunct> dbus-daemon processes.
This is after verifying that /usr/share/dbus-1/system.conf has the correct path:
  <listen>unix:path=/run/dbus/system_bus_socket</listen>

However, if I make /var/run a bind mount to /run during early boot, then
everything works as expected.

I can't find any evidence of anything in dbus itself still trying to use /var/run for anything (nothing in the code itself, no strings in the various binaries and libraries), and yet clearly something somewhere is. 

What the heck?? :-)

(In reply to Robby Workman from comment #1)
> With 1.12.0 here, if I pass the following configure flags:
>   --with-system-pid-file=/run/dbus/dbus.pid \
>   --with-system-socket=/run/dbus/system_bus_socket \
> with /run and /var/run being *separate* then I have a wonky system

Yes, that is currently expected. /var/run/dbus/system_bus_socket is the interoperable path that is hard-coded everywhere (in both dbus, and reimplementations like GLib's GDBus and systemd's sd-bus).

> I can't find any evidence of anything in dbus itself still trying to use
> /var/run for anything (nothing in the code itself, no strings in the various
> binaries and libraries), and yet clearly something somewhere is. 

What you're missing is that dbus (the reference implementation of D-Bus) is not the only thing on your system that implements the D-Bus protocol. Your system probably has important processes that use either GDBus or sd-bus (or possibly one of the rarer reimplementations like dbus-java or ndesk-dbus).

The question is: why are your /run and /var/run separate? Which operating system is this, and have you deliberately made them separate to see what happens, or is this a normal, supported configuration of that OS?

As far as I'm aware, the operating systems that adopted /run all require it to be equivalent to /var/run: either /var/run is a bind mount of /run, or /var/run is a symbolic link to /run, or the other way round. systemd sets this up (/usr/lib/tmpfiles.d/var.conf), and non-systemd Linux systems often require/guarantee it too (sysvinit >= 2.88dsf-13.3 in Debian and its derivatives sets this situation up, and Debian Policy §9.1.1.8 guarantees it).

However, if I'm wrong about that and there are common OSs that consider a separate /var/run and /run to be a supported configuration, then we cannot make this change, at least on those OSs.

> However, if I make /var/run a bind mount to /run during early boot, then
> everything works as expected.

That is also expected. If /var/run and /run are made somehow equivalent (bind-mount or symbolic link) then client programs connecting to /var/run/dbus/system_bus_socket will transparently connect to a server listening on /run/dbus/system_bus_socket.

In systemd we explicitly do not support any systems that do not have /var/run → /run linked up. If you do anything else, then you are out of warranty.

In fact, we even consider systems like that "tainted":

https://github.com/systemd/systemd/blob/master/src/core/dbus-manager.c#L160

We added a /run tmpfs quite some time ago when some things started requiring it, but left everything to use /var/run, so yes, /var/run and /run are separate for now. 

Essentially, changing the dbus configure flags to use /run for everything was an experiment - the goal here is to make everything use /run instead of /var/run to the extent possible. 

Yes, we can unify /var/run and /run quite easily - that's not the question. That's  definitely the goal here -- I was just curious as to what would break and why if we didn't.

Re making the change to use /run, I don't see why a distro here and there still using /var/run should prevent it -- it's easy enough for us/them to start using /run (it's already present anyway) instead.

We're not tainted by systemd, so whether systemd considers us tainted is irrelevant ;-)

Much appreciation for the responses, gentlemen.

(In reply to Robby Workman from comment #4)
> We're not tainted by systemd, so whether systemd considers us tainted is
> irrelevant ;-)

Well, /run is actually a systemd thing. See http://www.h-online.com/open/news/item/Linux-distributions-to-include-run-directory-1219006.html for example. So if you want to avoid all systemdisms, better also avoid /run altogether. I hear we are infectious...

(In reply to Robby Workman from comment #4)
> We added a /run tmpfs quite some time ago when some things started requiring
> it, but left everything to use /var/run, so yes, /var/run and /run are
> separate for now.

Who is "we"?

> Yes, we can unify /var/run and /run quite easily - that's not the question.
> That's  definitely the goal here -- I was just curious as to what would
> break and why if we didn't.

If your /var/run and /run are distinct, programs that use /var/run for particular "API" paths (like the system bus socket) will fail to interoperate with programs that use /run - each "API" path needs to document either /var/run or /run, and must only be accessed via that path, not the other one. This means the upstreams of portable software older than 2011 (like dbus) have to stick to /var/run, because otherwise our software will fail to interoperate with older versions of itself.

If you want your OS to be part of the solution and not part of the problem, please guarantee that /var/run and /run are equivalent (symlink, Linux bind-mount, FreeBSD nilfs or similar). If you can't do that or are not willing to do that, please don't have a /run at all. IMO having a /run with semantics that don't match the early adopters (all the distros where systemd is mandatory, plus Debian and its derivatives) is worse than not having /run at all.

If you are using shell-script-based boot (such as sysv-rc or OpenRC), you might find Debian's sysv-rc useful. All versions since mid 2011 have ensured that /var/run and /run are equivalent. This is the implementation used on Debian systems that are not using systemd, and as far as I know, the implementation used in Devuan.

> Re making the change to use /run, I don't see why a distro here and there
> still using /var/run should prevent it -- it's easy enough for us/them to
> start using /run (it's already present anyway) instead.

Yes, it's easy to start using /run. That isn't under question. What is more questionable is whether system services that do so will break interoperability. In your OS, it does break interoperability. This makes your OS a blocker for dbus making this change, unless you want us to consider your OS to be irrelevant.

(In reply to Lennart Poettering from comment #5)
> (In reply to Robby Workman from comment #4)
> > We're not tainted by systemd, so whether systemd considers us tainted is
> > irrelevant ;-)
> 
> Well, /run is actually a systemd thing. See
> http://www.h-online.com/open/news/item/Linux-distributions-to-include-run-
> directory-1219006.html for example. So if you want to avoid all systemdisms,
> better also avoid /run altogether. I hear we are infectious...


/run is a good idea. We're not opposed to good ideas. :-)


(In reply to Simon McVittie from comment #6)
> (In reply to Robby Workman from comment #4)
> Who is "we"?


We = Slackware


> Yes, it's easy to start using /run. That isn't under question. What is more
> questionable is whether system services that do so will break
> interoperability. In your OS, it does break interoperability. This makes
> your OS a blocker for dbus making this change, unless you want us to
> consider your OS to be irrelevant.


I guess we already are since we've not adopted systemd, so...

Look, I don't have particularly strong feelings about systemd, and I don't want to make this bug about systemd. We've not adopted systemd and have no current plans to do so, but that should not be interpreted as anything other than what it is. Basically, what we have meets our needs and we like it. If either or both of those change, then we'll re-evaluate.

Once again, thanks for the information - it was very helpful.

(In reply to Robby Workman from comment #7)
> > Yes, it's easy to start using /run. That isn't under question. What is more
> > questionable is whether system services that do so will break
> > interoperability. In your OS, it does break interoperability. This makes
> > your OS a blocker for dbus making this change, unless you want us to
> > consider your OS to be irrelevant.
> 
> I guess we already are since we've not adopted systemd, so...

To be clear, dbus does not require systemd and is not intended to require systemd. It works fine on sysvinit-booted Debian systems and on various non-Linux kernels, for example.

It is possible that future versions of dbus will require a systemd-compatible /run (or a Debian-compatible /run if you prefer), i.e. one that can be accessed through a symlink or bind-mount at /var/run for compatibility with older software. Obviously I'd prefer it if Slackware had one of those, so that people aren't reporting bugs about D-Bus being broken on Slackware. If that's how we implement it, then a runtime check/warning similar to the one in systemd would probably be part of it.

If Slackware is going to have /run, then I would strongly recommend implementing the same semantics as in systemd and Debian: /run should be equivalent to /var/run (with /var/run being a symlink or bind-mount). The migration path implemented in Debian's sysv-rc/initscripts packages (I forget which one actually does it) in mid 2011 might be a useful starting point. If you aren't opposed to good ideas, please take this good idea too :-)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/180.