In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
Please contact the D-Bus upstream mailing list if you are interested
in implementing a user bus without systemd. You will need something
resembling pam_xdg_support (which is what Ubuntu used before they
switched to systemd) to provide the XDG_RUNTIME_DIR,
Wrong tense. (-: I already gave it to people with nosh version 1.20
back in September 2015. The external configuration import subsystem
sets up a user-dbus service bundle for each "real person" user account
that it recognizes (i.e. not user accounts with nologin or with
well-known Debian/FreeBSD/PC-BSD system account names). I fixed up the
FreeBSD side, to not attempt the malfunctioning address=systemd:, in
nosh version 1.22 in November 2015. No, I do not need a PAM module.
In terms of needs, what I actually need is for you to respect the final
paragraph of the environment section of the XDG Base Directory
Specification, if you are not respecting it already, which I hope that
you are but suspect that you might not be.
*
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
As for what I would like, I'd like you (where that's plural, including
Joe Marcus Clarke or whomever else) to please make either
address=systemd: or address=unix:runtime=yes work in your program on
FreeBSD/PC-BSD/OpenBSD. If for the former you're relying upon a library
that the systemd authors have gradually made less and less
cross-platform since the dizzy heights of "should compile fine on the
most exotic Unixes" in 2010, then 2016 might be the time to look at
Cameron T. Norman's or Pierre-Yves Ritschard's code instead. (-:
*
https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#CrippledAdoption
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
The traditional D-Bus session bus uses abstract Unix sockets on Linux,
to ensure automatic cleanup even if the dbus-daemon is terminated
uncleanly. These sockets are always shared with container-based
sandboxes, unless you start a new network namespace (which unshares
all abstract Unix sockets, and also IP networking). The user bus uses
a single filesystem-backed socket per uid, which is easy to inspect
with standard Unix tools ("everything is a file") and is more
container-friendly: it is not shared by default, but can be shared
with a simple bind mount.
It makes it more BSD-friendly, too. As I said, make address=systemd:
work, and the nosh toolset (for one) gets you the ability to outright
*not care* about what the sockets are in the D-Bus broker at all, as
it's perfectly capable of handing your program already-open file
descriptors to listening sockets and a couple of environment variables.
systemd most definitely did not invent *that* idea, after all. The
Linux service bundles (built as aforementioned by the external
configuration import subsystem) do exactly that. The
FreeBSD/PC-BSD/OpenBSD service bundles could, were it not for the fact
that your program doesn't have a way of being told to use the protocol.
In fact, they *actually do* open the socket and pass it to your program
with the environment variables. But there's no way to tell your program
that that is happening. Please make your program actually capable of
understanding address=systemd: on FreeBSD/PC-BSD/OpenBSD.
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
Some desktop environment core components, such as GNOME's
gnome-session, will automatically start a session bus per login
session using dbus-launch if there is not already one available. [...]
["X11 autolaunching"] mode is discouraged, and not particularly
reliable: it has a tendency to start the dbus-daemon in a somewhat
precarious situation, as a child of some random GUI app with arbitrary
environment variables, resource limits, std{in,out,err} fds and so on.
PCDMd, kdm, gdm, and lxdm on PC-BSD have some fairly poor behaviour in
this area, such as for each session starting up a Desktop Bus broker
running as the superuser in addition to starting one up as the logged-in
user, because every man and his dog seems to consider it xyr
responsibility to spawn off a Desktop Bus broker process. They ignore
already-provided broker addresses in several cases, and kdeinit adds
even more "fun" to the mixture. One can run PCDMd, kdm, gdm, and lxdm
under nosh service management, and it would be good for the programs in
the login session(s) to just expect "/run/user/$UID/..." sockets, as one
already obtains from running "user" Desktop Bus brokers under nosh
service management.
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
dbus-daemon is not a fully-featured service manager:
Quite! Are you prepared, five years on, to go another round with
Lennart Poettering then? (-:
* https://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html
