[Pkg-utopia-maintainers] Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Simon McVittie]

On Sun, 05 Mar 2023 at 15:49:51 +0100, Martin Steigerwald wrote:
> Simon McVittie - 05.03.23, 12:58:48 CET:
> > How is your `dbus-daemon --session` process started? Is it started by
> > /etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching?
> > What is its current working directory?
> 
> It seems to be run with:
> 
> % cat run
> #!/usr/bin/env /lib/runit/invoke-run
> #Copyright: 2022-2023 Lorenzo Puliti <[…]>

This script does not start a session bus (notice the --system argument and
the absence of a --session argument):

> exec dbus-daemon --system --nofork --nopidfile

so it would be incorrect for $DBUS_SESSION_BUS_ADDRESS to point to
the socket it is listening on (which should be /run/dbus/system_bus_socket
rather than /tmp/anything).

This looks like a runit-specific script to start the *system* bus: a
runit equivalent of the /lib/systemd/system/dbus.service and
/etc/init.d/dbus in the dbus package.

The system bus, `dbus-daemon --system`, is a system-wide bus (one per
machine) for system services like elogind, polkit and NetworkManager. The
session bus, `dbus-daemon --session`, is a per-session bus (one per
X11 session or one per (machine,uid) pair) for per-user services like
kwallet. They're implemented by running the same code with different
configuration, but they are not interchangeable. Practical desktop
systems need both.

> % ps aux | grep "[d]bus"

If you were using systemd I'd suggest using systemd-cgls to get a logical
overview of how the various processes in the system fit together. There's
an obvious flaw in that suggestion for a runit user, but perhaps the
non-default-init community has something equivalent that can keep track of
how processes relate to each other even in the presence of daemonization?

> sddm      6587  0.0  0.0   6652  2316 ?        S    Mär04   0:00 dbus-launch --autolaunch 3d6f92a09aa53b38614887db63ce99a6 --binary-syntax --close-stderr
> sddm      6614  0.0  0.0   4404  2128 ?        Ss   Mär04   0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session

You are correct to say that those two are unlikely to be involved in
the issue you reported, because this is the per-user or per-X11-display
session bus for uid "sddm", and is not involved with the management of
per-user processes for uid "martin".

The arguments passed to sddm's dbus-launch are consistent with it having
been started by X11 autolaunching by some sddm component.

I suspect that this means sddm's login screen is implemented as a
miniature version of an ordinary X11 GUI session, with some special
settings to make it behave differently. It's a reasonable design to use,
and the "greeter" in GNOME's gdm behaves similarly.

> martin    9106  0.0  0.0   6740  2424 ?        S    Mär04   0:00 /usr/bin/dbus-launch --exit-with-session --sh-syntax
> martin    9107  0.0  0.0   7096  4696 ?        Ss   Mär04   0:12 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session

*Those* look like the implementation of your per-user or
per-X11-display session bus for uid "martin". I can't tell how they
were started (and it's up to you to find out), but the arguments
that were passed to dbus-launch are the same ones it would get from
/etc/X11/Xsession.d/75dbus_dbus-launch, and the consecutive process IDs
are reasonably strong evidence that dbus-daemon process 9107 was started
by dbus-launch process 9106 (or at least around the same time).

/etc/X11/Xsession.d/75dbus_dbus-launch inherits its execution environment
from whatever component runs the Xsession script (often a display manager,
and in your case presumably sddm). If you want "session stuff" to be
started with your home directory as the current working directory, then
making sure the Xsession script runs with that same working directory
is a good idea.

Editing or adding some scripts in Xsession.d so they write their current
working directory and other relevant information to the system log using
logger(1) might be a good direction for debugging this.

> > On a non-systemd-based system, when not using dbus-user-session, or
> > for a session service that does not have a corresponding
> > SystemdService, the dbus-daemon forks and execs the service as a
> > child process (or it might be a "daemonized" grandchild process, it's
> > a while since I looked at that code path). The session service will
> > probably inherit the dbus-daemon's current working directory,
> > whatever that happens to be.
> 
> I just wonder how that worked out in pre-systemd times in Debian. Cause
> KRunner definitely did not have "/" as its current working directory at the
> time.

Perhaps you could bring up a pre-systemd Debian system (wheezy or older)
in a VM, and find out? An older live-CD image is probably the easiest
way, since that avoids the need to have a working mirror for EOL suites
that were moved to archive.debian.org already.

(Of course, pre-systemd Debian systems booted with sysv-rc and sysvinit,
so comparing them to modern Debian with sysv-rc and sysvinit would
involve fewer variables than Devuan with runit.)

    smcv