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=d...@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
