Fwd: Re: Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

Martin Steigerwald martin at lichtvoll.de
Sun Mar 5 13:57:35 GMT 2023


Wow… my bug report to Debian regarding the dbus-x11 current working 
directory issue triggered quite a lengthy response by Simon with a lot 
of details.

I will need some time to digest this. Just forwarding at the moment in 
case you have any feedback or ideas on how to move on.

I also reported this to Devuan

dbus-x11: Several processes in Plasma session including krunner have / 
as current working directory


but I still hope that possibly a solution can be found that will work 
for Debian users as well. This would also reduce the diff Devuan 
developers have to carry around.

It seems that Simon is willing to consider a patch, but we from the non-
systemd community would have to come up with a proposal.

Also Simon shared the interesting idea to ask upstream to make sure 
current working directory is correct as D-BUS according to him does not 
document any particular guarantees about the current working directory.

I will try to answer at least some of Simon's questions. Will leave 
others for a later time as it would require me to setup a virtual 
machine with Debian to verify. Although I admit I expect no fundamental 
differences to Devuan regarding the behavior I reported.


----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Bug#1032368: dbus-x11: Several processes in Plasma session 
including krunner have / as current working directory
Datum: Sonntag, 5. März 2023, 12:58:48 CET
Von: Simon McVittie <smcv at debian.org>
An: Martin <Martin at lichtvoll.de>, 1032368 at bugs.debian.org

On Sun, 05 Mar 2023 at 09:33:08 +0100, Martin wrote:
> This is with Devuan Ceres with Runit and Elogind. I am reporting this
> with Debian as well, cause I think it is an issue in Debian as well

This bug tracking system is for Debian, not Devuan. Is this reproducible
on a Debian system with elogind, KDE and some non-systemd init system,
perhaps by using a virtual machine?

(In particular, I am not responsible for decisions made by the Devuan
maintainers of dbus. The version number 1.14.6-1devuan1 indicates that 
has been patched in some way, presumably to disable systemd integration 
perhaps for other reasons as well. I don't know what changes have been 
and I cannot confirm that they are all correct.)

In my experience, sysv-rc and openrc (sysvinit as process 1) are 
better-integrated in Debian than runit. Is this reproducible with sysv-
or openrc?

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?

/etc/X11/Xsession.d/75dbus_dbus-launch is the way dbus-daemon is meant
to be started on most Debian-derived systems that are not using
`systemd --user`. It starts the `dbus-daemon --session` as part of X
session startup, inheriting its current working directory and various
other aspects of its execution environment (such as rlimits) from the
X session startup scripts.

X11 autolaunching is the way `dbus-daemon --session` was traditionally
started on systems that are less well-integrated than Debian (the
classic use-case is something like "I want to run Firefox under twm on
Solaris"). In X11 autolaunching, dbus-launch is started as a daemonized
child process of whatever arbitrary process happens to have been the
first one to use D-Bus, which means it will inherit its current working
directory and other aspects of its execution environment (such as 
from that arbitrary process. This is obviously not good, because the
dbus-daemon should have a predictable execution environment, but it's
also not really fixable within X11 autolaunching because of the way
it works. I would consider most problems with X11 autolaunching to be
"won't fix" as a result, because their best solution will be to start
the session dbus-daemon during X session startup instead, either one
per X11 display with /etc/X11/Xsession.d/75dbus_dbus-launch, or one per
(machine,uid) pair with dbus-user-session (currently only possible on
systemd systems because nobody has contributed an implementation of that
behaviour for non-systemd).

I'm considering disabling X11 autolaunching in the Debian packaging of
dbus for Debian 13, since in practice its main function on modern 
is to make error messages more misleading. This would mean that the only
ways to get a session bus are /etc/X11/Xsession.d/75dbus_dbus-launch,
or dbus-user-session, or a parent process explicitly starting one.

Of course, if I do that, the Devuan maintainers of dbus could revert
that change if they want to, at their own risk.

> Without
> % cat /usr/share/dbus-1/services/org.kde.krunner.service
> [D-BUS Service]
> Name=org.kde.krunner
> Exec=/usr/bin/krunner
> SystemdService=plasma-krunner.service
> (file is from package plasma-workspace)
> KRunner is not started at all.

I don't use Plasma myself, so I don't know what krunner is or what it
does. Having it be an autostarted D-Bus session service (which means it
won't start if that file is removed) seems like an entirely reasonable
design choice.

For comparison, on a test VM with Debian 12 alpha and a
mostly-unconfigured Plasma, running on systemd, I do not initially have
a krunner process at all. If I force it to be started by running

    dbus-send --session --dest=org.kde.krunner --print-reply / 

then it's run as a systemd "user service" with current working directory 
my home directory.

D-Bus does not document any particular guarantees about the current
working directory for session services. If it is functionally important
for krunner to have its current working directory equal to the user's 
directory, then I would have expected that krunner should set that up 
itself during startup, with something like (untested, I don't know Qt):

    if (!QDir::setCurrent(QDir::homePath())) {
        qWarning("unable to chdir to home directory");

which would make it independent of how a parent process happens to have
run it. In particular, that would make the behaviour of krunner when
run from your shell during debugging more similar to its behaviour when
started as a D-Bus or systemd service.

> According to pstree krunner's parent process is runit which of course 
> has current working directory pointing to /.

If krunner's parent process is process 1, I would expect that it has
been run from somewhere else in the process hierarchy and "daemonized",
rather than having been started as a direct child of process 1, so that
doesn't necessarily mean anything.

> For Systemd based systems Plasma uses Systemd service files for 
startup, so
> dbus-x11 is not involved.

I think this indicates a misunderstanding of how this works and what
dbus-x11 does. dbus-x11 is never *directly* involved in how a D-Bus
service is started. However, it is *indirectly* involved, because dbus-
is responsible for launching the `dbus-daemon --session` process, and it
is the `dbus-daemon --session` process that is responsible for starting
D-Bus session services like krunner.

For a D-Bus session service like krunner with SystemdService= in its
D-Bus .service file, on systemd-based systems with dbus-user-session
installed, the dbus-daemon asks `systemd --user` via IPC to start the
corresponding systemd service. The dbus-daemon and krunner will both be
systemd user services, therefore they will both have the home directory
as current working directory unless specifically configured otherwise,
because systemd documents that behaviour.

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 
code path). The session service will probably inherit the dbus-daemon's
current working directory, whatever that happens to be.

A possible way to address this would be for either dbus-launch or
`dbus-daemon --session` to explicitly chdir() to the home directory
during its startup, which would bring the non-systemd code path one step
closer to being like the systemd code path.

However, the way that this whole code path works is the same way it has
worked for about 15 years, so my main concern about adding an explicit
chdir() would be whether it will cause other users of non-systemd 
to complain that adding it has caused a behaviour change that breaks 
workflow. Users of "more traditional" code paths and components such as
non-systemd init systems are often using those code paths because they
don't want behaviour changes, so the desired maintenance model for those
code paths is often "don't touch anything unless absolutely necessary",
particularly if they are poorly-understood upstream (definitely the case
for dbus-launch, which is mostly 15 year old legacy code).

The higher-level thing here is that dbus-daemon is not really a
fully-featured service manager (and is not designed to be one either),
and a lot of aspects of its behaviour are implementation details.
`systemd --user` *is* a "real" service manager, but it's one that Devuan
users don't want to use; and part of not using a "real" service manager
is missing out on service-management features, like having a well-defined
initial state for the execution environment of services.

> Using X11 still. With Wayland this issue does not happen. But there 
> too many other issues with Wayland still.

I don't know how startup of the D-Bus session bus under Wayland on
non-systemd systems is meant to work. As far as I know, Wayland 
don't generally run /etc/X11/Xsession.d (or at least, GNOME doesn't).
Honestly I'm a little surprised if it does work: I would generally have
expected Wayland systems to be relying on dbus-user-session, which is
currently only implemented for systemd systems.

If your Wayland session is starting a D-Bus session bus in some other
way (perhaps via X11 autolaunching, or perhaps your Wayland compositor
explicitly runs dbus-launch, dbus-run-session or dbus-daemon?) and it's
not the same as how /etc/X11/Xsession.d/75dbus_dbus-launch does it,
then presumably there is some implementation detail that results in the
session bus inheriting the home directory as current working directory.

> In case
> you are not willing to look into this issue please tell, so another
> solution or workaround can be found. I will also report this in 

I'd consider patches if a patch is proposed, but I am not in a position
to spend a lot of time on researching non-default init systems, or on
researching whether a proposed patch will have unintended consequences 
a different non-default init system. Please reach consensus on what the
non-systemd community wants, and then propose a change in dbus upstream
if appropriate.



More information about the Debian-init-diversity mailing list