Re: im-config and systemd --user (was: Mass bug filing: use and misuse of dbus-launch)
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
Reply to: