Date: Mon, 29 Aug 2016 11:11:29 -0400 From: Joe Marcus Clarke <marcus@freebsd.org> To: FreeBSD GNOME Users <gnome@freebsd.org> Subject: Fwd: Mass bug filing: use and misuse of dbus-launch (dbus-x11) Message-ID: <304cb53b-c5e4-ca3a-e43a-556f93b5c0a2@freebsd.org> In-Reply-To: <f7dd21f6-0fcf-0520-0879-2170fb8dbfbe@NTLWorld.com> References: <f7dd21f6-0fcf-0520-0879-2170fb8dbfbe@NTLWorld.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just got sent this. I think the broader team needs to see it and confirm what Jonathan is asking. Joe -------- Forwarded Message -------- Subject: Mass bug filing: use and misuse of dbus-launch (dbus-x11) Date: Mon, 29 Aug 2016 15:49:55 +0100 From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Debian Developers <debian-devel@lists.debian.org> CC: Joe Marcus Clarke <marcus@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?304cb53b-c5e4-ca3a-e43a-556f93b5c0a2>