Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mass bug filing: use and misuse of dbus-launch (dbus-x11)
256 views
Skip to first unread message
Simon McVittie
Aug 28, 2016, 10:00:02 AM8/28/16
to
I'm about to do a mass-bug-filing against packages that mention
dbus-x11 in their dependencies, or dbus-launch in their code, asking
maintainers to adjust their dependencies to make dbus-x11 optional.
My goal is that users can install the major desktop tasks in stretch
(GNOME, KDE, etc.) with either one of dbus-user-session or dbus-x11,
defaulting to dbus-user-session for new installations.
A dd-list of packages likely to be affected (based on
<https://codesearch.debian.net/search?q=dbus-%28x11|launch%29>)
is attached. Some of these will be false positives that merely
mention dbus-launch in documentation or example code, like qt4-x11;
I'll filter those out when I categorise them by type of dbus-launch
use during bug filing.
I will be prioritizing key packages for my MBF, then fill in non-key
packages afterwards.
tl;dr version:
* Search this mail for "Recommendations" for what you should do if you
are a maintainer of one of several categories of package.
* I think we should default to dbus-user-session for stretch on Linux.
* dbus-launch (dbus-x11) without dbus-user-session should continue to
be supported, but should be a non-default configuration on Linux.
* On kFreeBSD and Hurd, dbus-launch is still the best we can do.
* Regression tests should use dbus-run-session, not dbus-launch,
on all kernels.
* Fallback plan: make it possible for early adopters to use
dbus-user-session instead of dbus-launch, but keep dbus-launch the
default for new installs even on Linux, and reconsider for stretch+1.
My proposed solutions will make it possible to move to this
fallback plan by modifying src:dbus and nothing else.
Background: ways you might get a session bus
============================================
As of current stable, the correct way to start a "production"
D-Bus session in Debian was for /etc/X11/Xsession.d to invoke
dbus-launch(1). This would result in a session bus (dbus-daemon) per
X11 display, and is set up by the dbus-x11 package. The dbus-daemon
terminates when the X11 display does.
dbus 1.10 in testing/unstable introduces a new way for systemd users
to get a D-Bus session bus per uid (the *user bus*), shared between
all parallel logins whether they are X11, Wayland, Mir, text or
non-interactive. This is not 100% compatible with traditional practice,
particularly if you have two or more parallel X11 logins with the same uid
(GNOME's gdm won't do that, but some other display managers do), which
is why it is "opt-in". In Debian, this is not done by default, but can be
activated by installing the dbus-user-session package. In this case the
dbus-daemon terminates when "systemd --user" does, which is when the uid
responsible for this dbus-daemon ends their last parallel login session.
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. I believe GNOME on
Wayland currently relies on this mechanism if dbus-user-session is not
installed. This session bus terminates when the X11 display does (in the
case of GNOME on Wayland, the X11 display is XWayland, and terminates
when gnome-shell does). Similarly, regression tests sometimes start a
fake X11 display (Xvfb) and run dbus-launch scoped to that X11 display.
Another possible way to get a session bus is to run dbus-run-session(1),
or run dbus-daemon directly (typically using its --print-address
option). This is frequently done by regression tests. In this case,
a dbus-daemon started by dbus-run-session is terminated when
dbus-run-session's child process terminates, and a directly-run
dbus-daemon must be killed by the test script at the appropriate time.
Finally, if you start a program that uses D-Bus with no session bus
running, and you have an X11 display, the D-Bus library (typically
libdbus or GLib's GDBus) will attempt "X11 autolaunching": the program
forks and execs dbus-launch in a special "autolaunching" mode, and the
various dbus-launch processes that were started in this way attempt to
acquire a hidden X11 resource. Whichever dbus-launch process happens to
get there first forks and execs the dbus-daemon for this X11 session,
then continues to run to supervise it; the other dbus-launch processes
just report its address back to their parents and then terminate.
This 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.
Autolaunching can also get used if you run a graphical program under
su/sudo with access to your X11 display (but seriously, don't do that).
X11 autolaunching may have been important 10 years ago, when people
installed D-Bus into distributions that didn't otherwise integrate it,
and used it to run individual GNOME or KDE apps inside a fvwm session
or something. However, in 2016 and in a well-integrated distribution
like Debian, I would be inclined to treat any use of X11 autolaunching
as a bug.
Why should we prefer dbus-user-session?
=======================================
* If a GUI login session is running (for example you are logged-in
to a GUI environment but the screen is locked), your cron jobs and ssh
sessions on the same machine can share the desktop's user-services like
dconf, Telepathy, fd.o Secrets (gnome-keyring/KWallet).
* It's a good fit for the design of user-services like dconf.
They can take a bus name on the user bus and be confident that
this acts as a mutex locking out other instances of the user service
on the same machine, avoiding "last write wins" data loss for all
configurations where $HOME is not shared between machines.
* It's also very suitable for taking per-user daemons that use D-Bus
and would more usually be run in a desktop login session (for example
exporting media to a UPnP receiver like a PS3 using Rygel, with Tracker
for indexing) and turning them into pseudo-system-services running as
a dedicated user: a systemd service with PAMName= and User= is enough
to get a systemd --user instance and an accompanying dbus-daemon for
that user, which is enough to support services like Rygel.
* dbus-daemon is not a fully-featured service manager: it can start
session services on-demand, but it doesn't support resource limiting,
disabling services, non-D-Bus services and so on (nor should it - that
isn't in its scope, and it doesn't have enough regular contributors
to be a good idea to expand its scope to something like that). The
user bus can use a fully-featured service manager, "systemd --user",
for service activation.
* As a systemd user service, the user bus is started in a known context
with predictable/controllable environment variables, resource limits and
so on.
* 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.
* dbus-launch is fairly horrible code, complicated by the historical
need for it to support X11 autolaunching, so the D-Bus maintainers
would like to move it out of the critical path and minimize its use.
Why should dbus-user-session be optional?
=========================================
* The current implementation[1] requires systemd and systemd-logind.
This is not portable to non-Linux kernels, and upsets some Linux users.
[This is not set in stone; there's no reason why someone couldn't
write a PAM module that started a user bus, but the people doing the
work so far are happy with systemd taking responsibility for that.]
* Some desktop environments (including many configurations of "build
your own desktop environment from pieces") do support multiple
parallel X11 sessions per uid per machine. In these setups, the
user bus breaks the expectations of software that assumes it can run
once per X11 session, in parallel, and take the same bus name on the
session bus corresponding to each X11 session (for example
gnome-settings-daemon has this behaviour).
[It is possible to use a bus name like com.example.MyService.X0
if you want a bus name per X11 display, although this would require
coordinated code changes in the service and its consumers.]
* The per-X11-session bus would disconnect all background services
(or at least those that happen to use D-Bus) on each X11 logout;
well-behaved D-Bus services respond to this by terminating. The user
bus isn't normally terminated until all processes in the login session
have exited, which can result in background services lingering
(more precisely, if a login-session process lingers, then the
dbus-daemon and other non-GUI processes will too).
[If this is important to you, for example in a university computer lab,
consider using systemd-logind's KillUserProcesses option, which is
the default upstream since 230 but not in Debian; it's more thorough,
and does not depend on the implementation detail of whether processes
happen to use D-Bus for IPC.]
Recommendations for libraries
=============================
This recommendation applies to library implementations of D-Bus such
as libdbus, GLib's GDBus, systemd's sd-bus, dbus-sharp and dbus-java,
when connecting to the standard session bus.
If the environment variable DBUS_SESSION_BUS_ADDRESS is set, libraries
must use that address when asked to connect to the session bus.
If DBUS_SESSION_BUS_ADDRESS is unset, but XDG_RUNTIME_DIR is set,
and $XDG_RUNTIME_DIR/bus is a socket owned by the correct uid,
libraries must use that socket (for instance by substituting the
XDG_RUNTIME_DIR, escaped as a D-Bus address component, into
"unix:path=${escaped_xdg_runtime_dir}/bus").
If neither of those is available, libraries may use X11 autolaunching
(the "autolaunch:" pseudo-transport) like libdbus and GDBus do, or
they may simply fail the connection attempt like sd-bus does. I
anticipate that for stretch+1 or stretch+2, we might want to recommend
that libraries like libdbus and GDBus should disable X11 autolaunching,
and fail to connect in the circumstances where they would have used it.
Recommendations for desktop sessions
====================================
This recommendation applies to desktop sessions like GNOME, and desktop
sessions' core infrastructure like gnome-session.
Desktop sessions that make use of D-Bus should depend on
Depends: default-dbus-session-bus | dbus-session-bus
If a desktop environment works better with the "user bus" (I anticipate
that GNOME might do this in stretch or stretch+1), it may indicate
that with:
Depends: dbus-user-session | dbus-session-bus
Recommends: dbus-user-session
If a desktop environment strictly depends on the "user bus", please talk
to db...@packages.debian.org.
Desktop sessions may execute dbus-launch if they are started with
DBUS_SESSION_BUS_ADDRESS absent from the environment, and either
XDG_RUNTIME_DIR unset, or a socket named $XDG_RUNTIME_DIR/bus not existing
or owned by the wrong uid. This code path should not run in Debian X11
sessions or with dbus-user-session installed, but might be useful in
Wayland sessions with dbus-user-session not installed, or as part of
upstream support for distributions with less careful X11 integration
than Debian.
Recommendations for regression tests
====================================
This recommendation applies to packages that run tests at build time,
packages with autopkgtests, and all similar situations.
Regression tests should either use dbus-run-session, which is an "adverb"
command like sudo or fakeroot:
Depends: dbus (>= 1.8)
dbus-run-session -- make check
or if finer control is needed, start a dbus-daemon the hard way, something
like this:
Depends: dbus
#!/bin/sh
dbus-daemon --session --fork --print-address=4 --print-pid=5 4>address.tmp 5>pid.tmp
trap 'kill $(cat pid.tmp); rm -f address.tmp pid.tmp' EXIT
export DBUS_SESSION_BUS_ADDRESS="$(cat address.tmp)"
make check
If a special configuration file for the dbus-daemon is required, use
dbus-run-session --config=special.conf -- make check
or
dbus-daemon --config=special.conf --fork --print-address=4 ...
Recommendations for other software that relies on D-Bus
=======================================================
This recommendation applies to ordinary apps that rely on having a
session bus but are not a core part of a desktop environment, such as
the Empathy real-time communications client. These packages should rely
on the distribution and the desktop environment cooperating to ensure
that a session bus is provided.
A hard requirement for a session bus should be indicated like this:
Depends: default-dbus-session-bus | dbus-session-bus
A softer requirement can be indicated by a similar Recommends or Suggests.
These packages should not attempt to run dbus-launch or dbus-daemon,
except as a side-effect of using a library that supports X11
autolaunching - it is not their responsibility.
Discussion/contact
==================
Please discuss this MBF on debian-devel or by contacting
db...@packages.debian.org.
[1] 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,
plus some way to start the actual dbus-daemon, probably from the
same or a different PAM module. Note that since Ubuntu does not
use or maintain pam_xdg_support any more, you will likely need to
become its new upstream maintainer, or fork it as a basis for your
new PAM module.
Regards,
S
dbus-x11 in their dependencies, or dbus-launch in their code, asking
maintainers to adjust their dependencies to make dbus-x11 optional.
My goal is that users can install the major desktop tasks in stretch
(GNOME, KDE, etc.) with either one of dbus-user-session or dbus-x11,
defaulting to dbus-user-session for new installations.
A dd-list of packages likely to be affected (based on
<https://codesearch.debian.net/search?q=dbus-%28x11|launch%29>)
is attached. Some of these will be false positives that merely
mention dbus-launch in documentation or example code, like qt4-x11;
I'll filter those out when I categorise them by type of dbus-launch
use during bug filing.
I will be prioritizing key packages for my MBF, then fill in non-key
packages afterwards.
tl;dr version:
* Search this mail for "Recommendations" for what you should do if you
are a maintainer of one of several categories of package.
* I think we should default to dbus-user-session for stretch on Linux.
* dbus-launch (dbus-x11) without dbus-user-session should continue to
be supported, but should be a non-default configuration on Linux.
* On kFreeBSD and Hurd, dbus-launch is still the best we can do.
* Regression tests should use dbus-run-session, not dbus-launch,
on all kernels.
* Fallback plan: make it possible for early adopters to use
dbus-user-session instead of dbus-launch, but keep dbus-launch the
default for new installs even on Linux, and reconsider for stretch+1.
My proposed solutions will make it possible to move to this
fallback plan by modifying src:dbus and nothing else.
Background: ways you might get a session bus
============================================
As of current stable, the correct way to start a "production"
D-Bus session in Debian was for /etc/X11/Xsession.d to invoke
dbus-launch(1). This would result in a session bus (dbus-daemon) per
X11 display, and is set up by the dbus-x11 package. The dbus-daemon
terminates when the X11 display does.
dbus 1.10 in testing/unstable introduces a new way for systemd users
to get a D-Bus session bus per uid (the *user bus*), shared between
all parallel logins whether they are X11, Wayland, Mir, text or
non-interactive. This is not 100% compatible with traditional practice,
particularly if you have two or more parallel X11 logins with the same uid
(GNOME's gdm won't do that, but some other display managers do), which
is why it is "opt-in". In Debian, this is not done by default, but can be
activated by installing the dbus-user-session package. In this case the
dbus-daemon terminates when "systemd --user" does, which is when the uid
responsible for this dbus-daemon ends their last parallel login session.
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. I believe GNOME on
Wayland currently relies on this mechanism if dbus-user-session is not
installed. This session bus terminates when the X11 display does (in the
case of GNOME on Wayland, the X11 display is XWayland, and terminates
when gnome-shell does). Similarly, regression tests sometimes start a
fake X11 display (Xvfb) and run dbus-launch scoped to that X11 display.
Another possible way to get a session bus is to run dbus-run-session(1),
or run dbus-daemon directly (typically using its --print-address
option). This is frequently done by regression tests. In this case,
a dbus-daemon started by dbus-run-session is terminated when
dbus-run-session's child process terminates, and a directly-run
dbus-daemon must be killed by the test script at the appropriate time.
Finally, if you start a program that uses D-Bus with no session bus
running, and you have an X11 display, the D-Bus library (typically
libdbus or GLib's GDBus) will attempt "X11 autolaunching": the program
forks and execs dbus-launch in a special "autolaunching" mode, and the
various dbus-launch processes that were started in this way attempt to
acquire a hidden X11 resource. Whichever dbus-launch process happens to
get there first forks and execs the dbus-daemon for this X11 session,
then continues to run to supervise it; the other dbus-launch processes
just report its address back to their parents and then terminate.
This 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.
Autolaunching can also get used if you run a graphical program under
su/sudo with access to your X11 display (but seriously, don't do that).
X11 autolaunching may have been important 10 years ago, when people
installed D-Bus into distributions that didn't otherwise integrate it,
and used it to run individual GNOME or KDE apps inside a fvwm session
or something. However, in 2016 and in a well-integrated distribution
like Debian, I would be inclined to treat any use of X11 autolaunching
as a bug.
Why should we prefer dbus-user-session?
=======================================
* If a GUI login session is running (for example you are logged-in
to a GUI environment but the screen is locked), your cron jobs and ssh
sessions on the same machine can share the desktop's user-services like
dconf, Telepathy, fd.o Secrets (gnome-keyring/KWallet).
* It's a good fit for the design of user-services like dconf.
They can take a bus name on the user bus and be confident that
this acts as a mutex locking out other instances of the user service
on the same machine, avoiding "last write wins" data loss for all
configurations where $HOME is not shared between machines.
* It's also very suitable for taking per-user daemons that use D-Bus
and would more usually be run in a desktop login session (for example
exporting media to a UPnP receiver like a PS3 using Rygel, with Tracker
for indexing) and turning them into pseudo-system-services running as
a dedicated user: a systemd service with PAMName= and User= is enough
to get a systemd --user instance and an accompanying dbus-daemon for
that user, which is enough to support services like Rygel.
* dbus-daemon is not a fully-featured service manager: it can start
session services on-demand, but it doesn't support resource limiting,
disabling services, non-D-Bus services and so on (nor should it - that
isn't in its scope, and it doesn't have enough regular contributors
to be a good idea to expand its scope to something like that). The
user bus can use a fully-featured service manager, "systemd --user",
for service activation.
* As a systemd user service, the user bus is started in a known context
with predictable/controllable environment variables, resource limits and
so on.
* 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.
* dbus-launch is fairly horrible code, complicated by the historical
need for it to support X11 autolaunching, so the D-Bus maintainers
would like to move it out of the critical path and minimize its use.
Why should dbus-user-session be optional?
=========================================
* The current implementation[1] requires systemd and systemd-logind.
This is not portable to non-Linux kernels, and upsets some Linux users.
[This is not set in stone; there's no reason why someone couldn't
write a PAM module that started a user bus, but the people doing the
work so far are happy with systemd taking responsibility for that.]
* Some desktop environments (including many configurations of "build
your own desktop environment from pieces") do support multiple
parallel X11 sessions per uid per machine. In these setups, the
user bus breaks the expectations of software that assumes it can run
once per X11 session, in parallel, and take the same bus name on the
session bus corresponding to each X11 session (for example
gnome-settings-daemon has this behaviour).
[It is possible to use a bus name like com.example.MyService.X0
if you want a bus name per X11 display, although this would require
coordinated code changes in the service and its consumers.]
* The per-X11-session bus would disconnect all background services
(or at least those that happen to use D-Bus) on each X11 logout;
well-behaved D-Bus services respond to this by terminating. The user
bus isn't normally terminated until all processes in the login session
have exited, which can result in background services lingering
(more precisely, if a login-session process lingers, then the
dbus-daemon and other non-GUI processes will too).
[If this is important to you, for example in a university computer lab,
consider using systemd-logind's KillUserProcesses option, which is
the default upstream since 230 but not in Debian; it's more thorough,
and does not depend on the implementation detail of whether processes
happen to use D-Bus for IPC.]
Recommendations for libraries
=============================
This recommendation applies to library implementations of D-Bus such
as libdbus, GLib's GDBus, systemd's sd-bus, dbus-sharp and dbus-java,
when connecting to the standard session bus.
If the environment variable DBUS_SESSION_BUS_ADDRESS is set, libraries
must use that address when asked to connect to the session bus.
If DBUS_SESSION_BUS_ADDRESS is unset, but XDG_RUNTIME_DIR is set,
and $XDG_RUNTIME_DIR/bus is a socket owned by the correct uid,
libraries must use that socket (for instance by substituting the
XDG_RUNTIME_DIR, escaped as a D-Bus address component, into
"unix:path=${escaped_xdg_runtime_dir}/bus").
If neither of those is available, libraries may use X11 autolaunching
(the "autolaunch:" pseudo-transport) like libdbus and GDBus do, or
they may simply fail the connection attempt like sd-bus does. I
anticipate that for stretch+1 or stretch+2, we might want to recommend
that libraries like libdbus and GDBus should disable X11 autolaunching,
and fail to connect in the circumstances where they would have used it.
Recommendations for desktop sessions
====================================
This recommendation applies to desktop sessions like GNOME, and desktop
sessions' core infrastructure like gnome-session.
Desktop sessions that make use of D-Bus should depend on
Depends: default-dbus-session-bus | dbus-session-bus
If a desktop environment works better with the "user bus" (I anticipate
that GNOME might do this in stretch or stretch+1), it may indicate
that with:
Depends: dbus-user-session | dbus-session-bus
Recommends: dbus-user-session
If a desktop environment strictly depends on the "user bus", please talk
to db...@packages.debian.org.
Desktop sessions may execute dbus-launch if they are started with
DBUS_SESSION_BUS_ADDRESS absent from the environment, and either
XDG_RUNTIME_DIR unset, or a socket named $XDG_RUNTIME_DIR/bus not existing
or owned by the wrong uid. This code path should not run in Debian X11
sessions or with dbus-user-session installed, but might be useful in
Wayland sessions with dbus-user-session not installed, or as part of
upstream support for distributions with less careful X11 integration
than Debian.
Recommendations for regression tests
====================================
This recommendation applies to packages that run tests at build time,
packages with autopkgtests, and all similar situations.
Regression tests should either use dbus-run-session, which is an "adverb"
command like sudo or fakeroot:
Depends: dbus (>= 1.8)
dbus-run-session -- make check
or if finer control is needed, start a dbus-daemon the hard way, something
like this:
Depends: dbus
#!/bin/sh
dbus-daemon --session --fork --print-address=4 --print-pid=5 4>address.tmp 5>pid.tmp
trap 'kill $(cat pid.tmp); rm -f address.tmp pid.tmp' EXIT
export DBUS_SESSION_BUS_ADDRESS="$(cat address.tmp)"
make check
If a special configuration file for the dbus-daemon is required, use
dbus-run-session --config=special.conf -- make check
or
dbus-daemon --config=special.conf --fork --print-address=4 ...
Recommendations for other software that relies on D-Bus
=======================================================
This recommendation applies to ordinary apps that rely on having a
session bus but are not a core part of a desktop environment, such as
the Empathy real-time communications client. These packages should rely
on the distribution and the desktop environment cooperating to ensure
that a session bus is provided.
A hard requirement for a session bus should be indicated like this:
Depends: default-dbus-session-bus | dbus-session-bus
A softer requirement can be indicated by a similar Recommends or Suggests.
These packages should not attempt to run dbus-launch or dbus-daemon,
except as a side-effect of using a library that supports X11
autolaunching - it is not their responsibility.
Discussion/contact
==================
Please discuss this MBF on debian-devel or by contacting
db...@packages.debian.org.
[1] 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,
plus some way to start the actual dbus-daemon, probably from the
same or a different PAM module. Note that since Ubuntu does not
use or maintain pam_xdg_support any more, you will likely need to
become its new upstream maintainer, or fork it as a basis for your
new PAM module.
Regards,
S
Jonathan de Boyne Pollard
Aug 29, 2016, 11:10:02 AM8/29/16
to
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#CrippledAdoptionIn 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
Simon McVittie
Aug 31, 2016, 6:50:02 AM8/31/16
to
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'
> 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.
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=db...@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.
"""
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.
(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
Jonathan de Boyne Pollard
Sep 4, 2016, 12:50:02 PM9/4/16
to
Simon McVittie:
> 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.
>
That's the problem. No the whole unix:runtime=yes mechanism is not. As
I said, this is something that you and Joe Marcus Clarke and whomever
else have to sort out with each other. I'm unfortunately stuck in the
middle, here. Please do whatever it is that you need to do with each
other to make your program understand address=systemd: and
address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not do so.
Simon McVittie:
> 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".
>
Kudos for being the first project to offer integration, ever. (-: Yes,
down the road it would be marvellous if people included service bundles
in their own projects. Yes, I'd like to see the day when the number of
service bundles in the nosh-bundles package actually starts going down,
because people are taking on shipping their own service bundles for
their own services, instead of going up. So yes, eventually you'll be
taken up on that offer I hope. But one step at a time.
Simon McVittie:
>> 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.
>
There you go, then. New knowledge. (-: It doesn't work with your
program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is the
porter for FreeBSD, according to the port information, and Antoine
Jacoutot the porter for OpenBSD. This is why I am saying that it's
something that you (plural, remember) need to sort out amongst
yourselves. We users stuck in the middle cannot use address=systemd:
and address=unix:runtime=yes with your program on these systems. As I
said, it's something that I had to fix in November 2015, to stop trying
to use address=systemd: on FreeBSD/TrueOS because it turned out that it
didn't actually work. I thought that address=unix:runtime=yes might,
but that did not either.
Simon McVittie:
> 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";
>
Luckily, you didn't need to. The page that I hyperlinked before pointed
directly to Pierre-Yves Ritschard's and Cameron T. Norman's actual code,
even down to positioning the window around the first lines of the
functions. Now if one *did* want to follow the Debian way of having
mention of these things buried down in the depths, in a bug report from
years ago, then this is a truly excellent example of the genre that one
could enjoy. One should begin with Cameron T. Norman's post here,
roughly one thousand eight hundred messages down, in a bug report from 3
years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1859 (-:
Simon McVittie:
> 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, [...]
>
That's not the right way to look at it. You yourself have just said
several times that this is stuff that is supposed to be on "supported
Unix platforms". This isn't giving new things to anyone. This is
making existing things, that you yourself think are existing, work.
I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD
(now rebranded as TrueOS Desktop a few days ago -- I just got through
changing a whole load of preset file and -run package names.) is the BSD
that comes in the box with the desktop environments and with all of the
desktop programs that use Desktop Bus. Yes, people can and do run all
of this stuff on FreeBSD and OpenBSD from ports. But PC-BSD^H^H^H^H^H^H
... Gah! ... TrueOS Desktop is where it comes in the box and is run as
standard in the default install. TrueOS Desktop is where one ends up
choosing from running PCDMd, kdm, lxdm, or gdm; and where one gets lots
of little Desktop Bus brokers all over the place in various ways from
these different systems. TrueOS Desktop is where the people who are
behind the operating system will be strongly motivated towards improving
the desktop subsystems and the Desktop Bus.
You're pushing your new way of per-user Desktop Bus brokers at the
world. I can give the TrueOS Desktop people, and the the UbuntuBSD
people, and the Debian FreeBSD people, a service management system that
I know can run per-user Desktop Bus brokers on a FreeBSD kernel. It
already does. I published it last year. If you, the Desktop Bus people,
can give us these mechanisms in your program actually working on these
operating systems, then the TrueOS people get the opportunity to
simplify some of the scaffolding that they have had to erect
(PCDM-session writing out nonce scripts that invoke dbus-launch, for
example), and you get less of the world still using your old way of
doing things.
> 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.
>
I said, this is something that you and Joe Marcus Clarke and whomever
else have to sort out with each other. I'm unfortunately stuck in the
middle, here. Please do whatever it is that you need to do with each
other to make your program understand address=systemd: and
address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not do so.
Simon McVittie:
> 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".
>
down the road it would be marvellous if people included service bundles
in their own projects. Yes, I'd like to see the day when the number of
service bundles in the nosh-bundles package actually starts going down,
because people are taking on shipping their own service bundles for
their own services, instead of going up. So yes, eventually you'll be
taken up on that offer I hope. But one step at a time.
Simon McVittie:
>> 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.
>
program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is the
porter for FreeBSD, according to the port information, and Antoine
Jacoutot the porter for OpenBSD. This is why I am saying that it's
something that you (plural, remember) need to sort out amongst
yourselves. We users stuck in the middle cannot use address=systemd:
and address=unix:runtime=yes with your program on these systems. As I
said, it's something that I had to fix in November 2015, to stop trying
to use address=systemd: on FreeBSD/TrueOS because it turned out that it
didn't actually work. I thought that address=unix:runtime=yes might,
but that did not either.
Simon McVittie:
> 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";
>
directly to Pierre-Yves Ritschard's and Cameron T. Norman's actual code,
even down to positioning the window around the first lines of the
functions. Now if one *did* want to follow the Debian way of having
mention of these things buried down in the depths, in a bug report from
years ago, then this is a truly excellent example of the genre that one
could enjoy. One should begin with Cameron T. Norman's post here,
roughly one thousand eight hundred messages down, in a bug report from 3
years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1859 (-:
Simon McVittie:
> To be brutally honest, there is a fairly low limit to how much benefit
>
That's not the right way to look at it. You yourself have just said
several times that this is stuff that is supposed to be on "supported
Unix platforms". This isn't giving new things to anyone. This is
making existing things, that you yourself think are existing, work.
I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD
(now rebranded as TrueOS Desktop a few days ago -- I just got through
changing a whole load of preset file and -run package names.) is the BSD
that comes in the box with the desktop environments and with all of the
desktop programs that use Desktop Bus. Yes, people can and do run all
of this stuff on FreeBSD and OpenBSD from ports. But PC-BSD^H^H^H^H^H^H
... Gah! ... TrueOS Desktop is where it comes in the box and is run as
standard in the default install. TrueOS Desktop is where one ends up
choosing from running PCDMd, kdm, lxdm, or gdm; and where one gets lots
of little Desktop Bus brokers all over the place in various ways from
these different systems. TrueOS Desktop is where the people who are
behind the operating system will be strongly motivated towards improving
the desktop subsystems and the Desktop Bus.
You're pushing your new way of per-user Desktop Bus brokers at the
world. I can give the TrueOS Desktop people, and the the UbuntuBSD
people, and the Debian FreeBSD people, a service management system that
I know can run per-user Desktop Bus brokers on a FreeBSD kernel. It
already does. I published it last year. If you, the Desktop Bus people,
can give us these mechanisms in your program actually working on these
operating systems, then the TrueOS people get the opportunity to
simplify some of the scaffolding that they have had to erect
(PCDM-session writing out nonce scripts that invoke dbus-launch, for
example), and you get less of the world still using your old way of
doing things.
Jonathan de Boyne Pollard
Sep 4, 2016, 2:40:02 PM9/4/16
to
XDG Base Directory Specification:
> If $XDG_RUNTIME_DIR is not set applications should fall back to a
> replacement directory with similar capabilities and print a warning
> message
>
Simon McVittie:
> 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 [...]?
>
Simon McVittie:
> Using the same concrete value for the name of the XDG_RUNTIME_DIR that
> systemd does (/run/user/$numeric_uid) seems advisable, [...]
>
These two fit together, you know.
You think that a good "replacement directory" is /run/user/$EUID .
Alright. Then when your program is told address=unix:runtime=yes and
there's no XDG_RUNTIME_DIR, please make it fall back to using the
directory that you think is the advisable directory to use. (-:
At the moment, as far as I can see, when there's no XDG_RUNTIME_DIR
there's no fallback per the XDG specification at all. We all know that
XDG_RUNTIME_DIR has been a thorn in people's sides for years, where
there is a mismatch between the owner of the runtime directory and the
process' effective user. The irony is that you and your program would
get quite sensible behaviour without it, were you to make
address=unix:runtime=yes actually do the thing that you are here saying
is advisable. In the cases where address=unix:runtime=yes is used, and
when they are all doing what you say is advisable, your servers set up
their sockets in {/var,}/run/user/$UID/dbus_blah and your clients go
looking for those sockets in the same place, picking the right one for
the process' effective UID and rendezvousing in the right place.
And the people who still want XDG_RUNTIME_DIR still get to have it, and
all of its do-we-or-do-we-not-follow-euid-changes-maybe-sometimes joy
that the world has come to know and love.
This as well as having made address=unix:runtime=yes actually work in
the first place, of course. (-:
> 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
>
Simon McVittie:
> Using the same concrete value for the name of the XDG_RUNTIME_DIR that
>
These two fit together, you know.
You think that a good "replacement directory" is /run/user/$EUID .
Alright. Then when your program is told address=unix:runtime=yes and
there's no XDG_RUNTIME_DIR, please make it fall back to using the
directory that you think is the advisable directory to use. (-:
At the moment, as far as I can see, when there's no XDG_RUNTIME_DIR
there's no fallback per the XDG specification at all. We all know that
XDG_RUNTIME_DIR has been a thorn in people's sides for years, where
there is a mismatch between the owner of the runtime directory and the
process' effective user. The irony is that you and your program would
get quite sensible behaviour without it, were you to make
address=unix:runtime=yes actually do the thing that you are here saying
is advisable. In the cases where address=unix:runtime=yes is used, and
when they are all doing what you say is advisable, your servers set up
their sockets in {/var,}/run/user/$UID/dbus_blah and your clients go
looking for those sockets in the same place, picking the right one for
the process' effective UID and rendezvousing in the right place.
And the people who still want XDG_RUNTIME_DIR still get to have it, and
all of its do-we-or-do-we-not-follow-euid-changes-maybe-sometimes joy
that the world has come to know and love.
This as well as having made address=unix:runtime=yes actually work in
the first place, of course. (-:
Simon McVittie
Sep 5, 2016, 3:40:02 AM9/5/16
to
On Sun, 04 Sep 2016 at 19:24:09 +0100, Jonathan de Boyne Pollard wrote:
> You think that a good "replacement directory" is /run/user/$EUID . Alright.
> Then when your program is told address=unix:runtime=yes and there's no
> XDG_RUNTIME_DIR, please make it fall back to using the directory that you
> think is the advisable directory to use.
No, I think that /run/user/$EUID is a good choice for the OS infrastructure
> You think that a good "replacement directory" is /run/user/$EUID . Alright.
> Then when your program is told address=unix:runtime=yes and there's no
> XDG_RUNTIME_DIR, please make it fall back to using the directory that you
> think is the advisable directory to use.
(systemd-logind or equivalent) to make. D-Bus implementations are merely
one specific user of XDG_RUNTIME_DIR; it is not their place to
set a specific interpretation of how to fall back when this variable
is unset, and it is not their place to define semantics for /run/user,
a directory that you will notice does not mention dbus or D-Bus anywhere
in its name.
D-Bus implementations should use the XDG per-uid runtime directory as a
rendezvous point *if* that directory is going to have all the required
properties (specified lifetime guarantee, cleaned up automatically
on logout, etc.). OS infrastructure can signal that it provides those
properties for a directory, and indicate what the right directory is,
by arranging for that environment variable to be in user processes'
environments. If you want to use interoperable protocols that rely on
XDG_RUNTIME_DIR, set an XDG_RUNTIME_DIR, otherwise your protocol is not
going to be interoperable.
You are writing to the mailing list for the development of Debian, in a
thread about the src:dbus source package and how the rest of Debian should
interact with it. The dbus binary package deliberately does not *require*
the user-bus model, for the reasons I outlined in the mass bug filing;
the dbus-user-session source package does require the user-bus model,
but it also depends on packages that ensure that $XDG_RUNTIME_DIR is set.
Everything else is not relevant to Debian, until/unless it is in Debian.
S
[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=db...@packages.debian.org;tag=dbus-launch-unless-dsba
Simon McVittie
Sep 5, 2016, 5:10:02 AM9/5/16
to
On Sun, 04 Sep 2016 at 17:30:43 +0100, Jonathan de Boyne Pollard wrote:
> Simon McVittie:
<https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core>
Please follow the traditional bug-reporting template (steps to reproduce,
expected result, actual result). Tested patches are also welcome.
(As the commit message[1] says, unix:runtime=yes is intended to fail
if XDG_RUNTIME_DIR is unset; that's not considered to be a bug.)
If you want patches applied to dbus (the reference implementation of
D-Bus), please submit those patches for review in its bug tracking
system, in a bug report that describes the bug or missing feature that
those patches address. Links to your personal website, written in a form
that ensures that typical web browsers will reject the SSL certificate,
in a thread on the Debian mailing list for the development of Debian,
are not a recommended form of upstream patch submission - doubly so
for issues that specifically involve OSs that are not Debian and so
are off-topic for this mailing list.
Linking to other people's implementations of sd_listen_fds() is also
not a useful form of upstream patch submission. I am well aware that
it is possible to implement an API equivalent to sd_listen_fds() on
non-Linux OSs. I do not run those other OSs, and I am not going to test
dbus on those other OSs, so a link that effectively says "you could
do it something like this" is not particularly helpful: the proposed
change needs to be sufficiently specific that someone who *does* run
the relevant OS can easily test it. Until that testing is done, the
change won't be merged.
If you are more interested in those other OSs than I am, and want to
contribute tested improvements for them, please do so. If you want to
encourage others to contribute those improvements, or pay someone to do
so, that's also fine. However, debian-devel is not an appropriate
venue for any of those activities.
[1] https://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.10&id=e3f117e7610b0e0a91dfe5bff7bf2e217c129a86
> That's not the right way to look at it. You yourself have just said several
> times that this is stuff that is supposed to be on "supported Unix
> platforms". This isn't giving new things to anyone. This is making
> existing things, that you yourself think are existing, work.
As far as I'm aware, "the old way" - involving dbus-launch - works the
same on BSD as it does on Linux, and works the same on BSD in dbus 1.10
as it did in dbus 1.0.
The unix:runtime=yes listenable address is a new feature in 1.10.0
(actually 1.9.x, but that was an unstable development branch that led
to 1.10.x). As far as I'm aware, it works as intended on all Unix
platforms. Regardless of whether that is true or not, it does not
affect whether the previously-supported listenable addresses work on
those platforms.
unix:runtime=yes is not intended to work in the absence of an
XDG_RUNTIME_DIR; if your platform doesn't routinely set that variable
for user processes, and you have not taken any special steps to set it
in the dbus-daemon's environment, then attempting to listen on
unix:runtime=yes will fail. This is equally true on Linux and non-Linux.
> You're pushing your new way of per-user Desktop Bus brokers at the world.
This is the debian-devel mailing list, for the development of Debian.
I am one of Debian's dbus maintainers, and I would like Debian to default
to the user-bus model, at least for new installations on the Linux kernel.
Whether other operating systems do the same is up to the people with the
equivalent role in those other operating systems.
I don't find Debian's non-Linux ports particularly interesting, and
they are certainly not a majority configuration or one that I would
recommend to inexperienced users, so I don't consider changing the
default on those ports to be equally important. Some people consider
those ports to be important, and those people are invited to provide
tested patches. That bug tracker link again:
<https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core>
Non-Debian operating systems are not relevant to this mailing list, and
I regret getting drawn in to your discussion of them. Other operating
systems' dbus maintainers should make their own decision whether
their particular OS has a login-session bus or a user bus, and
contribute any patches that might be needed to make their chosen
interaction possible. The Arch Linux dbus maintainer did exactly that.
If *BSD dbus maintainers want to do the same, I've already mentioned
where the upstream bug tracker is.
> If you, the Desktop Bus people, can give us these
> mechanisms in your program actually working on these operating systems
> [...] you get less of the world still using
if my time, attention, skills and patience were unlimited, but since
there are limits to all of those, I have to prioritize. I work on D-Bus
partly because it's interesting, partly because it's an important part
of the OS I rely on (namely Debian GNU/Linux), and partly because my
employer considers it to be important to the projects I get paid for.
Porting to non-Linux is not a high priority for any of those reasons -
I don't find it fun, it doesn't benefit the Debian ports that I consider
to be most practically useful, and my employer doesn't pay me to support
alternative kernels. I'm willing to review tested patches, because that's
part of the job of being a maintainer, but I don't intend to write them.
If this is more important to you than it is to me, great - contribute
tested patches, or pay someone to do so.
S
> Simon McVittie:
> > 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.
> >
> There you go, then. New knowledge. (-: It doesn't work with your program
> as ported to FreeBSD/TrueOS/OpenBSD.
The D-Bus bug tracking system is over here:
> > (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.
> >
> There you go, then. New knowledge. (-: It doesn't work with your program
> as ported to FreeBSD/TrueOS/OpenBSD.
<https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core>
Please follow the traditional bug-reporting template (steps to reproduce,
expected result, actual result). Tested patches are also welcome.
(As the commit message[1] says, unix:runtime=yes is intended to fail
if XDG_RUNTIME_DIR is unset; that's not considered to be a bug.)
If you want patches applied to dbus (the reference implementation of
D-Bus), please submit those patches for review in its bug tracking
system, in a bug report that describes the bug or missing feature that
those patches address. Links to your personal website, written in a form
that ensures that typical web browsers will reject the SSL certificate,
in a thread on the Debian mailing list for the development of Debian,
are not a recommended form of upstream patch submission - doubly so
for issues that specifically involve OSs that are not Debian and so
are off-topic for this mailing list.
Linking to other people's implementations of sd_listen_fds() is also
not a useful form of upstream patch submission. I am well aware that
it is possible to implement an API equivalent to sd_listen_fds() on
non-Linux OSs. I do not run those other OSs, and I am not going to test
dbus on those other OSs, so a link that effectively says "you could
do it something like this" is not particularly helpful: the proposed
change needs to be sufficiently specific that someone who *does* run
the relevant OS can easily test it. Until that testing is done, the
change won't be merged.
If you are more interested in those other OSs than I am, and want to
contribute tested improvements for them, please do so. If you want to
encourage others to contribute those improvements, or pay someone to do
so, that's also fine. However, debian-devel is not an appropriate
venue for any of those activities.
[1] https://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.10&id=e3f117e7610b0e0a91dfe5bff7bf2e217c129a86
> That's not the right way to look at it. You yourself have just said several
> times that this is stuff that is supposed to be on "supported Unix
> platforms". This isn't giving new things to anyone. This is making
> existing things, that you yourself think are existing, work.
same on BSD as it does on Linux, and works the same on BSD in dbus 1.10
as it did in dbus 1.0.
The unix:runtime=yes listenable address is a new feature in 1.10.0
(actually 1.9.x, but that was an unstable development branch that led
to 1.10.x). As far as I'm aware, it works as intended on all Unix
platforms. Regardless of whether that is true or not, it does not
affect whether the previously-supported listenable addresses work on
those platforms.
unix:runtime=yes is not intended to work in the absence of an
XDG_RUNTIME_DIR; if your platform doesn't routinely set that variable
for user processes, and you have not taken any special steps to set it
in the dbus-daemon's environment, then attempting to listen on
unix:runtime=yes will fail. This is equally true on Linux and non-Linux.
> You're pushing your new way of per-user Desktop Bus brokers at the world.
I am one of Debian's dbus maintainers, and I would like Debian to default
to the user-bus model, at least for new installations on the Linux kernel.
Whether other operating systems do the same is up to the people with the
equivalent role in those other operating systems.
I don't find Debian's non-Linux ports particularly interesting, and
they are certainly not a majority configuration or one that I would
recommend to inexperienced users, so I don't consider changing the
default on those ports to be equally important. Some people consider
those ports to be important, and those people are invited to provide
tested patches. That bug tracker link again:
<https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core>
Non-Debian operating systems are not relevant to this mailing list, and
I regret getting drawn in to your discussion of them. Other operating
systems' dbus maintainers should make their own decision whether
their particular OS has a login-session bus or a user bus, and
contribute any patches that might be needed to make their chosen
interaction possible. The Arch Linux dbus maintainer did exactly that.
If *BSD dbus maintainers want to do the same, I've already mentioned
where the upstream bug tracker is.
> If you, the Desktop Bus people, can give us these
> mechanisms in your program actually working on these operating systems
> your old way of doing things.
There are all sorts of contributions to Free Software that I could make
if my time, attention, skills and patience were unlimited, but since
there are limits to all of those, I have to prioritize. I work on D-Bus
partly because it's interesting, partly because it's an important part
of the OS I rely on (namely Debian GNU/Linux), and partly because my
employer considers it to be important to the projects I get paid for.
Porting to non-Linux is not a high priority for any of those reasons -
I don't find it fun, it doesn't benefit the Debian ports that I consider
to be most practically useful, and my employer doesn't pay me to support
alternative kernels. I'm willing to review tested patches, because that's
part of the job of being a maintainer, but I don't intend to write them.
If this is more important to you than it is to me, great - contribute
tested patches, or pay someone to do so.
S
Steve Litt
Sep 5, 2016, 1:20:04 PM9/5/16
to
On Sun, 4 Sep 2016 17:30:43 +0100
Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.com>
wrote:
Danger Will Robinson.
"Integration" in cases of systemd and its venus fly trap, dbus, is more
Embrace, Extend, Extinguish than integration. The Rube Goldbergesque
system described in the preceding quoted context exquisitely highlights
that fact.
Do not cooperate with systemd. The systemd proponents don't cooperate
with anyone else.
> Yes, down the road it would be marvellous if people included service
> bundles in their own projects.
What would be marvellous is if people would simply ignore systemd,
opting for a real init system (not a conglomeration of welded krap
trying to supercede what we've had for years).
> Yes, I'd like to see the day when the
> number of service bundles in the nosh-bundles package actually starts
> going down, because people are taking on shipping their own service
> bundles for their own services, instead of going up. So yes,
> eventually you'll be taken up on that offer I hope. But one step at a
> time.
Ooohhhh, "service bundles." My runit run scripts average about 6 lines
long. Any fool can make them. Behold the power of a real init: An init
that knows it's an init, and does only what inits are designed to do. I
highlight runit out of familiarity, but my use of s6 and Epoch indicate
that both are equally as simple, when defining service startup, runit.
>
> Simon McVittie:
>
> >> 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.
> There you go, then. New knowledge. (-: It doesn't work with your
> program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is
> the porter for FreeBSD, according to the port information, and
> Antoine Jacoutot the porter for OpenBSD.
To the *BSD communities: Please do not let the systemd camel get his
nose in your tent. Systemd is a repudiation of everything Unix, created
by a guy who makes no bones of his hate for Posix.
> This is why I am saying
> that it's something that you (plural, remember) need to sort out
> amongst yourselves. We users stuck in the middle cannot use
> address=systemd: and address=unix:runtime=yes with your program on
> these systems. As I said, it's something that I had to fix in
> November 2015, to stop trying to use address=systemd: on
> FreeBSD/TrueOS because it turned out that it didn't actually work. I
> thought that address=unix:runtime=yes might, but that did not either.
>
[snip]
systemd.
> You yourself have just said
> several times that this is stuff that is supposed to be on "supported
> Unix platforms". This isn't giving new things to anyone. This is
> making existing things, that you yourself think are existing, work.
If these existing things can't be made to work without systemd
incorporation, they should be torn out and replaced. Encumbering a good
system with systemd is not the answer.
>
> I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD
> (now rebranded as TrueOS Desktop a few days ago -- I just got through
> changing a whole load of preset file and -run package names.) is the
> BSD that comes in the box with the desktop environments and with all
> of the desktop programs that use Desktop Bus. Yes, people can and do
> run all of this stuff on FreeBSD and OpenBSD from ports. But
> PC-BSD^H^H^H^H^H^H ... Gah! ... TrueOS Desktop is where it comes in
> the box and is run as standard in the default install. TrueOS
> Desktop is where one ends up choosing from running PCDMd, kdm, lxdm,
> or gdm; and where one gets lots of little Desktop Bus brokers all
> over the place in various ways from these different systems. TrueOS
> Desktop is where the people who are behind the operating system will
> be strongly motivated towards improving the desktop subsystems and
> the Desktop Bus.
To those who care about simplicity and user-maintainable software, the
preceding paragraph appears to be one possible strategy to continue
eliminating non-systemd choices. Beware.
>
> You're pushing your new way of per-user Desktop Bus brokers at the
> world. I can give the TrueOS Desktop people, and the the UbuntuBSD
> people, and the Debian FreeBSD people, a service management system
> that I know can run per-user Desktop Bus brokers on a FreeBSD
> kernel. It already does. I published it last year. If you, the
> Desktop Bus people, can give us these mechanisms in your program
> actually working on these operating systems, then the TrueOS people
> get the opportunity to simplify some of the scaffolding that they
> have had to erect (PCDM-session writing out nonce scripts that invoke
> dbus-launch, for example), and you get less of the world still using
> your old way of doing things.
LOL, per-user desktops.
There must be a zillion different ways to have sterminal hung off a
Linux box each get their own GUI. I'd do it myself, except that's not
my itch. In a world where a COTS desktop is $600 USD, laptop $500 USD,
and used but still perfectly functional computers can be had for
$50-$200, hanging terminals makes little economic sense. I'm sure the
systemd afficianados will find such a use case, and proclaim that use
case must be served, but we all know it's FUD.
The systemd folks shout from the mountaintops that sysvinit is 32 years
old or whatever, and how that alone is enough reason to use systemd,
and yet these same monuments to modern software proclaim their
multiseat, terminal-enabling technology is a reason to switch to
systemd, even though terminals had their heyday in 1984. Talk about
greybeards.
One more thing: They talk about dbus as if it's a good thing. Even
before systemd, I tried to stay away from a bus system that was pretty
much like a traffic circle enabling everything to talk to everything
else, addressing allowing. What could *possibly* go wrong?
The subject of this thread is "Mass bug filing: use and misuse of
dbus-launch (dbus-x11)". If you're a software user, use dbus as little
as possible. If you're a developer, find other communication methods,
and don't incorporate dbus. Because, as evidenced by this thread, dbus
is now just a pretty entry point to systemd.
SteveT
Steve Litt
Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.com>
wrote:
"Integration" in cases of systemd and its venus fly trap, dbus, is more
Embrace, Extend, Extinguish than integration. The Rube Goldbergesque
system described in the preceding quoted context exquisitely highlights
that fact.
Do not cooperate with systemd. The systemd proponents don't cooperate
with anyone else.
> Yes, down the road it would be marvellous if people included service
> bundles in their own projects.
opting for a real init system (not a conglomeration of welded krap
trying to supercede what we've had for years).
> Yes, I'd like to see the day when the
> number of service bundles in the nosh-bundles package actually starts
> going down, because people are taking on shipping their own service
> bundles for their own services, instead of going up. So yes,
> eventually you'll be taken up on that offer I hope. But one step at a
> time.
long. Any fool can make them. Behold the power of a real init: An init
that knows it's an init, and does only what inits are designed to do. I
highlight runit out of familiarity, but my use of s6 and Epoch indicate
that both are equally as simple, when defining service startup, runit.
>
> Simon McVittie:
>
> >> 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.
> There you go, then. New knowledge. (-: It doesn't work with your
> program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is
> the porter for FreeBSD, according to the port information, and
> Antoine Jacoutot the porter for OpenBSD.
nose in your tent. Systemd is a repudiation of everything Unix, created
by a guy who makes no bones of his hate for Posix.
> This is why I am saying
> that it's something that you (plural, remember) need to sort out
> amongst yourselves. We users stuck in the middle cannot use
> address=systemd: and address=unix:runtime=yes with your program on
> these systems. As I said, it's something that I had to fix in
> November 2015, to stop trying to use address=systemd: on
> FreeBSD/TrueOS because it turned out that it didn't actually work. I
> thought that address=unix:runtime=yes might, but that did not either.
>
>
> Simon McVittie:
>
> > 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, [...]
> >
> That's not the right way to look at it.
This is precisely the right way to look at it, when it pertains to
> Simon McVittie:
>
> > 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, [...]
> >
> That's not the right way to look at it.
systemd.
> You yourself have just said
> several times that this is stuff that is supposed to be on "supported
> Unix platforms". This isn't giving new things to anyone. This is
> making existing things, that you yourself think are existing, work.
incorporation, they should be torn out and replaced. Encumbering a good
system with systemd is not the answer.
>
> I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD
> (now rebranded as TrueOS Desktop a few days ago -- I just got through
> changing a whole load of preset file and -run package names.) is the
> BSD that comes in the box with the desktop environments and with all
> of the desktop programs that use Desktop Bus. Yes, people can and do
> run all of this stuff on FreeBSD and OpenBSD from ports. But
> PC-BSD^H^H^H^H^H^H ... Gah! ... TrueOS Desktop is where it comes in
> the box and is run as standard in the default install. TrueOS
> Desktop is where one ends up choosing from running PCDMd, kdm, lxdm,
> or gdm; and where one gets lots of little Desktop Bus brokers all
> over the place in various ways from these different systems. TrueOS
> Desktop is where the people who are behind the operating system will
> be strongly motivated towards improving the desktop subsystems and
> the Desktop Bus.
preceding paragraph appears to be one possible strategy to continue
eliminating non-systemd choices. Beware.
>
> You're pushing your new way of per-user Desktop Bus brokers at the
> world. I can give the TrueOS Desktop people, and the the UbuntuBSD
> people, and the Debian FreeBSD people, a service management system
> that I know can run per-user Desktop Bus brokers on a FreeBSD
> kernel. It already does. I published it last year. If you, the
> Desktop Bus people, can give us these mechanisms in your program
> actually working on these operating systems, then the TrueOS people
> get the opportunity to simplify some of the scaffolding that they
> have had to erect (PCDM-session writing out nonce scripts that invoke
> dbus-launch, for example), and you get less of the world still using
> your old way of doing things.
There must be a zillion different ways to have sterminal hung off a
Linux box each get their own GUI. I'd do it myself, except that's not
my itch. In a world where a COTS desktop is $600 USD, laptop $500 USD,
and used but still perfectly functional computers can be had for
$50-$200, hanging terminals makes little economic sense. I'm sure the
systemd afficianados will find such a use case, and proclaim that use
case must be served, but we all know it's FUD.
The systemd folks shout from the mountaintops that sysvinit is 32 years
old or whatever, and how that alone is enough reason to use systemd,
and yet these same monuments to modern software proclaim their
multiseat, terminal-enabling technology is a reason to switch to
systemd, even though terminals had their heyday in 1984. Talk about
greybeards.
One more thing: They talk about dbus as if it's a good thing. Even
before systemd, I tried to stay away from a bus system that was pretty
much like a traffic circle enabling everything to talk to everything
else, addressing allowing. What could *possibly* go wrong?
The subject of this thread is "Mass bug filing: use and misuse of
dbus-launch (dbus-x11)". If you're a software user, use dbus as little
as possible. If you're a developer, find other communication methods,
and don't incorporate dbus. Because, as evidenced by this thread, dbus
is now just a pretty entry point to systemd.
SteveT
Steve Litt
Andrey Rahmatullin
Sep 5, 2016, 2:00:02 PM9/5/16
to
At first, I thought it's a random set of words. Then I noticed that they
follow language rules and thought that it's a nicely crafted Markov chain
text designed to look like random babbling of a typical systemd-hater. It
looks like I was wrong after all.
--
WBR, wRAR
follow language rules and thought that it's a nicely crafted Markov chain
text designed to look like random babbling of a typical systemd-hater. It
looks like I was wrong after all.
--
WBR, wRAR
Osamu Aoki
Sep 18, 2016, 9:30:02 AM9/18/16
to
Hi from im-config maintainer.
> Osamu Aoki <os...@debian.org>
> im-config
On Sun, Aug 28, 2016 at 02:59:13PM +0100, Simon McVittie wrote:
> I'm about to do a mass-bug-filing against packages that mention
> dbus-x11 in their dependencies, or dbus-launch in their code, asking
> maintainers to adjust their dependencies to make dbus-x11 optional.
As a person who is involved with keyboard input methods for the
Chinese-Japanese-Korean-(... possibly Indic...) environment, relying on
dbus-x11 hook script to set the input method has been my concern,
considering GUI application on Wayland w/o X11 may be coming soon.
> My goal is that users can install the major desktop tasks in stretch
> (GNOME, KDE, etc.) with either one of dbus-user-session or dbus-x11,
> defaulting to dbus-user-session for new installations.
It sounds interesting and good direction, but this seems to require a
lot of efforts for infrastructure packages.
> A dd-list of packages likely to be affected (based on
> <https://codesearch.debian.net/search?q=dbus-%28x11|launch%29>)
> is attached. Some of these will be false positives that merely
> mention dbus-launch in documentation or example code, like qt4-x11;
> I'll filter those out when I categorise them by type of dbus-launch
> use during bug filing.
>
> I will be prioritizing key packages for my MBF, then fill in non-key
> packages afterwards.
MBF is fine. Please lead us with good example codes for typical cases
with wiki.debian.org articles explaining them.
> tl;dr version:
>
> * Search this mail for "Recommendations" for what you should do if you
> are a maintainer of one of several categories of package.
> * I think we should default to dbus-user-session for stretch on Linux.
> * dbus-launch (dbus-x11) without dbus-user-session should continue to
> be supported, but should be a non-default configuration on Linux.
Unless im-config has a way to set up a hook environment variable setting
mechanism for dbus-user-session, all CJKI-keyboard-input methods stop
functioning once dbus-x11 is removed and the following files are
missing:
/etc/X11/Xsession.d/75dbus_dbus-launch
Where is the equivalent location to put equivalent code such as
/etc/X11/Xsession.d/70im-config_launch
Wait ... 75dbus_dbus-launch seems to have gone through significant
change ... I see:
# See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815503>
I have "The hook script for dbus-launch is in 75 which changes $STARTUP
string." in the comment of im-config. The current dbus-launch in 75
does not touch $STARTUP any more. This change seems to break how
im-config uses $STARTUP.
Hmmm... I remember adding this dbus-launch comment to ensure passing
environment variables such as
* $XMODIFIERS
* $GTK_IM_MODULE
* $QT_IM_MODULE
* $QT4_IM_MODULE
* $CLUTTER_IM_MODULE
to programs started automatically when the session starts such as Ekiga
etc.
So listing im-config in MBF seems to be FALSE POSITIVE if it is only
based on this string in the comment.
But this change may require serious rethinking of im-config for how
these environment variables should be set for programs such as Ekiga
from im-config. Do you have idea? Or I do not need to worry????
Quite frankly, I am a bit lost how to handle situation ...
Your input is most appreciated.
Osamu
> Osamu Aoki <os...@debian.org>
> im-config
On Sun, Aug 28, 2016 at 02:59:13PM +0100, Simon McVittie wrote:
> I'm about to do a mass-bug-filing against packages that mention
> dbus-x11 in their dependencies, or dbus-launch in their code, asking
> maintainers to adjust their dependencies to make dbus-x11 optional.
Chinese-Japanese-Korean-(... possibly Indic...) environment, relying on
dbus-x11 hook script to set the input method has been my concern,
considering GUI application on Wayland w/o X11 may be coming soon.
> My goal is that users can install the major desktop tasks in stretch
> (GNOME, KDE, etc.) with either one of dbus-user-session or dbus-x11,
> defaulting to dbus-user-session for new installations.
lot of efforts for infrastructure packages.
> A dd-list of packages likely to be affected (based on
> <https://codesearch.debian.net/search?q=dbus-%28x11|launch%29>)
> is attached. Some of these will be false positives that merely
> mention dbus-launch in documentation or example code, like qt4-x11;
> I'll filter those out when I categorise them by type of dbus-launch
> use during bug filing.
>
> I will be prioritizing key packages for my MBF, then fill in non-key
> packages afterwards.
with wiki.debian.org articles explaining them.
> tl;dr version:
>
> * Search this mail for "Recommendations" for what you should do if you
> are a maintainer of one of several categories of package.
> * I think we should default to dbus-user-session for stretch on Linux.
> * dbus-launch (dbus-x11) without dbus-user-session should continue to
> be supported, but should be a non-default configuration on Linux.
mechanism for dbus-user-session, all CJKI-keyboard-input methods stop
functioning once dbus-x11 is removed and the following files are
missing:
/etc/X11/Xsession.d/75dbus_dbus-launch
Where is the equivalent location to put equivalent code such as
/etc/X11/Xsession.d/70im-config_launch
Wait ... 75dbus_dbus-launch seems to have gone through significant
change ... I see:
# See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815503>
I have "The hook script for dbus-launch is in 75 which changes $STARTUP
string." in the comment of im-config. The current dbus-launch in 75
does not touch $STARTUP any more. This change seems to break how
im-config uses $STARTUP.
Hmmm... I remember adding this dbus-launch comment to ensure passing
environment variables such as
* $XMODIFIERS
* $GTK_IM_MODULE
* $QT_IM_MODULE
* $QT4_IM_MODULE
* $CLUTTER_IM_MODULE
to programs started automatically when the session starts such as Ekiga
etc.
So listing im-config in MBF seems to be FALSE POSITIVE if it is only
based on this string in the comment.
But this change may require serious rethinking of im-config for how
these environment variables should be set for programs such as Ekiga
from im-config. Do you have idea? Or I do not need to worry????
Quite frankly, I am a bit lost how to handle situation ...
Your input is most appreciated.
Osamu
Simon McVittie
Dec 12, 2016, 11:30:02 AM12/12/16
to
Sorry for the long delay to this response; it got pre-empted by
something more urgent, and then I forgot about it.
On Sun, 18 Sep 2016 at 22:19:38 +0900, Osamu Aoki wrote:
> So listing im-config in MBF seems to be FALSE POSITIVE if it is only
> based on this string in the comment.
Yes, looks like a false positive. My dd-list was based on a simple search
for dbus-(x11|launch) on codesearch.debian.net. I didn't analyze its
results in detail before announcing the MBF, because by the time I'd gone
to the effort of inspecting each potentially-affected package, I had all
the necessary information to file a bug with concrete recommendations
for that package. The MBF is now complete (I think) and im-config
didn't receive a bug.
However, im-config is the sort of thing that might need adjustment to
work as intended with systemd user services. That's really outside
the scope of this MBF, but it's in the same sort of space.
> I have "The hook script for dbus-launch is in 75 which changes $STARTUP
> string." in the comment of im-config. The current dbus-launch in 75
> does not touch $STARTUP any more. This change seems to break how
> im-config uses $STARTUP.
The root problem here is that /etc/X11/Xsession.d does two orthogonal
things: it sets environment variables, and it also starts services
like dbus-daemon (and whatever input method is started by im-launch?),
some of which might themselves need environment variables (leading to
circular dependencies if we're not careful).
Increasingly, upstream software is solving this by using a real
service manager (systemd --user, aka user@${UID}.service) instead of
a directory full of shell scripts: if Xsession.d is like a per-user
version of /etc/init.d, then systemd --user is like a per-user version
of the pid 1 instance of systemd. dbus-user-session is the equivalent
of dbus-x11 for the systemd --user service manager. Another popular
option is to use freedesktop.org autostarting
(/etc/xdg/autostart/*.desktop), and rely on a freedesktop.org
session manager like gnome-session to read that directory.
What does im-launch do? Does it spawn subprocesses that are input
methods? If so, what environment variables (if any) do they need set
in their environment?
Does im-launch set environment variables? Can the values of those
environment variables be hard-coded in a script or based on simple
substitutions (like dbus-user-session's
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus) or are they
variable and hard to determine until services start (like dbus-x11's
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-5298fc9w or whatever
other socket name tempnam() chooses)?
For your reference, here is how the startup chain worked in jessie
(assuming GNOME just to have a concrete example, but gnome-session
could be replaced with any other desktop environment, window manager
or similar):
* 20dbus_xdg-runtime is absent
* At sequence number 50 or thereabouts, $STARTUP is something like
"gnome-session"
* 70im-config_launch sets a bunch of environment variables
and changes $STARTUP to "/usr/bin/im-launch gnome-session"
* 75dbus_dbus-launch changes $STARTUP from e.g. "gnome-session" to
"dbus-launch --exit-with-session /usr/bin/im-launch gnome-session"
* 99x11-common_start execs $STARTUP
Here is how it will work in stretch with dbus-x11 but without
dbus-user-session:
* 20dbus_xdg-runtime is absent
* At sequence number 50, $STARTUP is something like "gnome-session"
* 70im-config_launch sets a bunch of environment variables
and changes $STARTUP to "/usr/bin/im-launch gnome-session"
* 75dbus_dbus-launch starts dbus-launch and dbus-daemon
* 95dbus_update-activation-env takes any environment variables
that were set between 75dbus_dbus-launch and here, and sends them
to the dbus-daemon via a D-Bus method call, so that D-Bus session
services will also get those variables set (unless they were started
already)
* 99x11-common_start execs $STARTUP, as before
and in stretch with dbus-user-session:
* libpam-systemd tells systemd-logind that a login session was
started, and systemd-logind tells pid 1 to start the system
service user@$UID.service, i.e. systemd --user, which in turn
starts the user services dbus.socket and dbus.service, i.e.
dbus-daemon --session
* 20dbus_xdg-runtime puts
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus in the
environment
* At sequence number 50, $STARTUP is something like "gnome-session"
* 70im-config_launch sets a bunch of environment variables
and changes $STARTUP to "/usr/bin/im-launch gnome-session"
* If dbus-x11 is installed, 75dbus_dbus-launch sees that
DBUS_SESSION_BUS_ADDRESS is already installed and does nothing
* If dbus-x11 is installed, 95dbus_update-activation-env takes any
environment variables that were set before this point, and sends
them to the dbus-daemon and to systemd --user via a D-Bus
method call, so that D-Bus session services and systemd user
services will also get those variables set (unless they were
started already)
* 99x11-common_start execs $STARTUP, as before
Regards,
S
something more urgent, and then I forgot about it.
On Sun, 18 Sep 2016 at 22:19:38 +0900, Osamu Aoki wrote:
> So listing im-config in MBF seems to be FALSE POSITIVE if it is only
> based on this string in the comment.
for dbus-(x11|launch) on codesearch.debian.net. I didn't analyze its
results in detail before announcing the MBF, because by the time I'd gone
to the effort of inspecting each potentially-affected package, I had all
the necessary information to file a bug with concrete recommendations
for that package. The MBF is now complete (I think) and im-config
didn't receive a bug.
However, im-config is the sort of thing that might need adjustment to
work as intended with systemd user services. That's really outside
the scope of this MBF, but it's in the same sort of space.
> I have "The hook script for dbus-launch is in 75 which changes $STARTUP
> string." in the comment of im-config. The current dbus-launch in 75
> does not touch $STARTUP any more. This change seems to break how
> im-config uses $STARTUP.
things: it sets environment variables, and it also starts services
like dbus-daemon (and whatever input method is started by im-launch?),
some of which might themselves need environment variables (leading to
circular dependencies if we're not careful).
Increasingly, upstream software is solving this by using a real
service manager (systemd --user, aka user@${UID}.service) instead of
a directory full of shell scripts: if Xsession.d is like a per-user
version of /etc/init.d, then systemd --user is like a per-user version
of the pid 1 instance of systemd. dbus-user-session is the equivalent
of dbus-x11 for the systemd --user service manager. Another popular
option is to use freedesktop.org autostarting
(/etc/xdg/autostart/*.desktop), and rely on a freedesktop.org
session manager like gnome-session to read that directory.
What does im-launch do? Does it spawn subprocesses that are input
methods? If so, what environment variables (if any) do they need set
in their environment?
Does im-launch set environment variables? Can the values of those
environment variables be hard-coded in a script or based on simple
substitutions (like dbus-user-session's
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus) or are they
variable and hard to determine until services start (like dbus-x11's
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-5298fc9w or whatever
other socket name tempnam() chooses)?
For your reference, here is how the startup chain worked in jessie
(assuming GNOME just to have a concrete example, but gnome-session
could be replaced with any other desktop environment, window manager
or similar):
* 20dbus_xdg-runtime is absent
* At sequence number 50 or thereabouts, $STARTUP is something like
"gnome-session"
* 70im-config_launch sets a bunch of environment variables
and changes $STARTUP to "/usr/bin/im-launch gnome-session"
* 75dbus_dbus-launch changes $STARTUP from e.g. "gnome-session" to
"dbus-launch --exit-with-session /usr/bin/im-launch gnome-session"
* 99x11-common_start execs $STARTUP
Here is how it will work in stretch with dbus-x11 but without
dbus-user-session:
* 20dbus_xdg-runtime is absent
* At sequence number 50, $STARTUP is something like "gnome-session"
* 70im-config_launch sets a bunch of environment variables
and changes $STARTUP to "/usr/bin/im-launch gnome-session"
* 75dbus_dbus-launch starts dbus-launch and dbus-daemon
* 95dbus_update-activation-env takes any environment variables
that were set between 75dbus_dbus-launch and here, and sends them
to the dbus-daemon via a D-Bus method call, so that D-Bus session
services will also get those variables set (unless they were started
already)
* 99x11-common_start execs $STARTUP, as before
and in stretch with dbus-user-session:
* libpam-systemd tells systemd-logind that a login session was
started, and systemd-logind tells pid 1 to start the system
service user@$UID.service, i.e. systemd --user, which in turn
starts the user services dbus.socket and dbus.service, i.e.
dbus-daemon --session
* 20dbus_xdg-runtime puts
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus in the
environment
* At sequence number 50, $STARTUP is something like "gnome-session"
* 70im-config_launch sets a bunch of environment variables
and changes $STARTUP to "/usr/bin/im-launch gnome-session"
* If dbus-x11 is installed, 75dbus_dbus-launch sees that
DBUS_SESSION_BUS_ADDRESS is already installed and does nothing
* If dbus-x11 is installed, 95dbus_update-activation-env takes any
environment variables that were set before this point, and sends
them to the dbus-daemon and to systemd --user via a D-Bus
method call, so that D-Bus session services and systemd user
services will also get those variables set (unless they were
started already)
* 99x11-common_start execs $STARTUP, as before
Regards,
S
0 new messages