Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)
On Mon, 29 Aug 2016 at 15:49:55 +0100, Jonathan de Boyne Pollard wrote:
> 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.
This can already work. If you put XDG_RUNTIME_DIR in user programs'
environment, and arrange for your favourite service manager to make a
dbus-daemon (or something else that speaks the same protocol) listen
on $XDG_RUNTIME_DIR/bus before any user process would try to connect
to it, then modern versions of at least libdbus, GDBus and sd-bus will
connect to it by default with no additional effort on your part. This
client-side code path does not depend on systemd, does not depend on
libsystemd (except obviously sd-bus which is part of libsystemd), and
is compiled in for all supported Unix platforms.
To be nice to the smaller D-Bus client implementations (dbus-java,
dbus-sharp, etc.), and to programs that second-guess how D-Bus is to be
set up, setting user processes' DBUS_SESSION_BUS_ADDRESS to an appropriate
unix: address is strongly recommended. This is not strictly necessary if
your use cases are limited to the major D-Bus implementations - libdbus
(used by QtDBus, dbus-python, etc.), GDBus and sd-bus - and you do not
run any of the session managers etc. whose relevant bugs are listed in
<https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=dbus@packages.debian.org;tag=dbus-launch-unless-dsba>
(list is not necessarily complete, I'm about 80% through a grep-based
mass bug filing).
Alternatively, if you cut out the XDG_RUNTIME_DIR middle-man, arrange
for user processes' DBUS_SESSION_BUS_ADDRESS to be set to a value of
your choice, and arrange for your service manager to make a dbus-daemon
listen at that address, that should work in any reasonable D-Bus client
implementation going back at least a decade.
If you want to maintain equivalent integration as part
of your service manager or a third-party project, the current MBF
means you will be able to give the corresponding Debian package
"Provides: dbus-session-bus" and have it satisfy packages' dependencies.
Meanwhile, if you want the relevant integration files (your favourite
service manager's equivalent of systemd units) to be part of dbus (the
reference implementation of D-Bus), please propose tested patches; if
they follow the "user session" model[1], they could eventually go in
dbus-user-session.deb, with its dependencies changed from the current
systemd-sysv to "systemd-sysv | your-service-manager".
For any significant addition to dbus, the contributor will need to be
prepared to help support it - I don't run those other service managers,
so I won't be fixing them. Some systemd contributors, notably Lennart
Poettering from systemd upstream and Jan Alexander Steffens from Arch
Linux, have stepped up to support that aspect of the dbus codebase,
and I would expect similar ongoing contributions from the communities
around other service managers if people want that service manager to be
as well-supported by dbus as systemd is.
> 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.
Are you are referring to this?
"""
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message
"""
Are you saying that if XDG_RUNTIME_DIR is not set, D-Bus client libraries
should choose some arbitrary other directory that is conjectured to have
the same properties that the XDG_RUNTIME_DIR spec guarantees, look for
a ./bus socket in *that* directory, use it as the session bus if it exists
and has suitable ownership, and meanwhile write a warning message to
stderr? It is not at all clear to me how this behaviour would be useful:
D-Bus is only useful when it interoperates, and having each client
implementation choose an arbitrary fallback (that might not match
where your dbus-daemon is even listening) is not interoperable.
One reasonable fallback that I've seen used for a missing
XDG_RUNTIME_DIR is to create a new empty directory, and use that.
The implementation in libdbus could be interpreted as an optimized,
0-line implementation of that fallback, which elides the actual directory
creation and check for the socket on the basis that the latter will
never succeed in practice, because there is no way for the dbus-daemon
to know that it is expected to put a socket in a newly created directory.
The pragmatic way to make this work is to arrange for your favourite
alternative(s) to systemd to provide an XDG_RUNTIME_DIR with the
properties that are called for by its spec, and make user code inherit
that environment variable from it. At least two implementations exist:
systemd-logind (libpam-systemd) and libpam-xdg-runtime.
Using the same concrete value for the name of the XDG_RUNTIME_DIR
that systemd does (/run/user/$numeric_uid) seems advisable, because
there seems to be no compelling reason to choose a different value,
applications might be (incorrectly) following the systemd
implementation instead of the spec, and in particular for
D-Bus, incorrect implementations might fail to escape path
components that contain characters that are not allowed or have
a syntactic meaning in D-Bus address strings (which is not a
problem in practice under systemd, because its XDG_RUNTIME_DIRs
never contain such characters).
> 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.
To the best of my knowledge, the listenable address "unix:runtime=yes"
(as in "dbus-daemon --address=unix:runtime=yes") does work on generic
Unix, and should interoperate fine with the XDG_RUNTIME_DIR/bus fallback
used by clients with no DBUS_SESSION_BUS_ADDRESS. It is compiled and
tested whenever DBUS_UNIX is defined (i.e. everything except Windows),
and I haven't seen bug reports about that test failing.
The systemd: transport currently relies on libsystemd for its
implementation of the LISTEN_FDS protocol. I would not be opposed to
patches adding a code path that open-coded that protocol when building
without libsystemd (on systems where libsystemd *is* available, I
would prefer to continue to use it to minimize duplicate code). The most
pragmatic implementation of a fallback code path would be to provide
portable, drop-in-compatible reimplementations of the sd_listen_fds()
and sd_is_socket() APIs, for example copied from the older versions of
sd-daemon.[ch] that were designed to be a portable "copylib", together
with defining SD_LISTEN_FDS_START to 3.
I am not going to develop support for platforms I don't run, because
I am the most frequent reviewer, so those patches would likely sit in
Bugzilla unreviewed. Also, please bear in mind that my time to work
on D-Bus is limited: I have to choose where my work goes, with a focus
on what I believe to be the best effort:benefit ratios. To be brutally
honest, there is a fairly low limit to how much benefit I can create by
giving new things to PC-BSD users, when compared with the benefit I can
create by spending the same amount of time giving the same new things
to users of Debian, Ubuntu, Fedora, SuSE and similar GNU/Linux-based
OSs in their default configuration.
If you want to propose patches to the D-Bus Specification and its
reference implementation, I'm happy to review them. Again, my D-Bus time
is limited, so regression fixes, security fixes, things I get paid to
develop, etc. are going to take precedence, but I try to review
everything reasonably promptly.
I am *not* going to go looking for patches on display at the bottom of a
locked filing cabinet stuck in a disused lavatory with a sign on the door
saying "beware of the leopard"; if you want the specification or reference
implementation to change, then you will need to use its infrastructure to
propose patches. The reference implementation of D-Bus is under an
unusual dual-license for historical reasons, so I am reluctant to land
patches whose authors have not submitted the patch themselves with the
expectation that it will be merged.
S
[1] https://lists.freedesktop.org/archives/dbus/2015-January/016522.html
Reply to: