Re: Dbus change of location from system_bus_socket

Simon McVittie <smcv-ZGY8ohtN/[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <[email protected]>
On Wed, 23 May 2018 at 16:03:11 +0200, Lennart Poettering wrote:
> On systemd systems /var/run *must* be a symlink to /run, thus making
> both directories synonymous. This is explicitly documented, and if you
> don't have such a symlink in place you will encounter breakage all
> over the place.

This is also true on all Debian derivatives (whether they use systemd
or not) since around 2011, and is a design that I would strongly recommend
in all OS distributions that have a FHS-like filesystem layout. There is
no reason to make those directories distinct: it will only break things,
for no benefit.

The system dbus-daemon still canonically listens on
/var/run/dbus/system_bus_socket, and by default this is even true on
systemd systems. For example, Debian's /lib/systemd/system/dbus.socket
has ListenStream=/var/run/dbus/system_bus_socket. If the dbus package
in CentOS/RHEL listens on /run/dbus/system_bus_socket, that would have
to be a local change: please contact that distribution's support channels.

https://bugs.freedesktop.org/show_bug.cgi?id=101628 tracks our attempts to
change the upstream default system bus address from ${localstatedir}/run
(normally /var/run) to ${runstatedir} (often /run). Unfortunately,
some (IMO misguided) OS distributions have both /var/run and /run and
make them distinct (the only example I know of is Slackware). If you
maintain such a distribution, even if you do not use systemd, I would
strongly recommend the approach taken in Debian and Ubuntu (years before
we adopted systemd): /run should be a tmpfs, and /var/run should be a
symbolic link or a bind-mount to /run. See 2011-era Debian sysv-rc and
initscripts packages for the migration paths that we used back then.

    smcv
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.