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

[Martin Steigerwald]

Hi Simon and Lorenzo.

First off: Kudos and appreciation that you took the time to respond this
thoroughly. Thank you!

Dear Lorenzo, I am also CC'ing you since some of the findings may point
at that it may make sense to resolve this within the runit-services package.
However I am certainly not sure yet about that. Especially as it would
require a solution for other init systems than Runit as well. Indeed there
are several options to fix the issue that Simon outlined. One of them would
involve upstream activity in KDE. And another one could probably work
from dbus-x11. So much choice to get a clue about!

Simon McVittie - 05.03.23, 12:58:48 CET:
> 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 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?

I appreciate that. And I admit I did not yet test it in Debian. I consider
setting up a virtual machine to make sure.

> (In particular, I am not responsible for decisions made by the Devuan
> maintainers of dbus. The version number 1.14.6-1devuan1 indicates that

Fair enough! I could install the Debian Experimental version of the package,
but that still would not make this Devuan installation a Debian, so rather
going for the virtual machine approach.

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

Lorenzo confirmed this for SysVInit as well:

https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2023-February/005929.html

I asked for confirmation whether this confirmation is from a Devuan or a
Debian based system.

Also the KDE bug report I mentioned that this happens across distributions
and across different init systems¹. It originally has been reported for Gentoo.

[1] https://bugs.kde.org/432975

> 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?

I bet you mean the dbus service which

DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/dbus-uwFj[…],guid=9aaf[…]'

refers to. According to lsof this is running as PID 9107 currently.

Its parent process is runit. Its working directory is "/".

It seems to be run with:

% cat run
#!/usr/bin/env /lib/runit/invoke-run
#Copyright: 2022-2023 Lorenzo Puliti <[…]>
#License: CC0-1.0

exec 2>&1

if [ ! -d /var/run/dbus ]; then
    install -d /var/run/dbus -o messagebus -g messagebus
fi
mountpoint -q /proc/ || exit 162
if [ -x /usr/bin/dbus-uuidgen ]; then
    /usr/bin/dbus-uuidgen --ensure
fi

if [ -e /etc/runit/verbose ]; then
        echo "invoke-run: starting ${PWD##*/}"
fi
exec dbus-daemon --system --nofork --nopidfile

Well I bet basically that would explain its current working directory being
"/". However it would not explain it for a SysVInit based system.

Also above runit service comes from the runit-services package and the
issue has been already there before Lorenzo brought this package
into Debian and before I had it installed.

Grepping for processes with dbus in their name or arguments also reveals
one dbus service that appears to have been launched by sddm which
is the display manager I use:

% ps aux | grep "[d]bus"
root      1991  0.0  0.0   2344  1268 ?        Ss   Mär04   0:00 runsv dbus
root      1992  0.0  0.0   2344  1368 ?        Ss   Mär04   0:00 runsv dbus.dep-fixer
_runit-+  2015  0.0  0.0   2492  1452 ?        S    Mär04   0:00 svlogd -tt -b 2048 /var/log/runit/dbus
message+  2016  0.0  0.0   6536  4896 ?        S    Mär04   0:04 dbus-daemon --system --nofork --nopidfile
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
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
martin    9317  0.0  0.0 234536 25088 ?        Sl   Mär04   0:03 /usr/bin/gmenudbusmenuproxy

The working directory of PID 6614 is also /. I bet it is not related to the
bug I reported. It seems to be a special dbus service just for the display
manager and "/" as working directory may just be about right for that
one.

> /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.

I do have "/etc/X11/Xsession.d/75dbus_dbus-launch" on my system. But no
idea whether it is being used to start DBUS or not. To me currently it
appears that Runit is starting it.

> X11 autolaunching is the way `dbus-daemon --session` was traditionally
> started on systems that are less well-integrated than Debian (the
[…]
> I'm considering disabling X11 autolaunching in the Debian packaging of
> dbus for Debian 13, since in practice its main function on modern
[…]
> Of course, if I do that, the Devuan maintainers of dbus could revert
> that change if they want to, at their own risk.

Thank you for all that insight. I hope other members of the alternative init
systems community within Debian (some of which are also working for Devuan)
can chime in on this.

> > 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.

Sure. I was not questioning that. I just remember that in pre-systemd
times in Debian there has not been the issue of KRunner and various other
parts of Plasma running as processes with current working directory "/".

I am still trying to understand why that is and what would be the best
solution to fix that. Preferably with one nicely maintainable fix which
works for all the init systems. I understand that this is far away from your
primary concern as the default in Debian is Systemd.

KRunner is invoked by Alt-Space key combination. Then you just enter some
command, application name or something that one of the KRunner plugins
understand like "1 EUR in USD". Then it presents some answers that the user
can select for the appropriate action to be taken. Or it just shares some
information. Maybe call it a more sophisticated quick application runner.

Result of it having "/" as a working directory is that any application
started by it will also have "/" as working directory. Which is inconvenient
when a user chooses to save a file to a certain location as the file
dialog then starts from "/". Unless the application itself is using a
different default that is.

> 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 home directory, then I would have expected that krunner
> should set that up for 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.

Thank you. That could also be an option to suggest to upstream. Would 
wait for feedback by other members of the other init community before
probably suggesting that to upstream.

> > 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.

Sure.

> > 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-x11 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.

I just referred to that the plasma-workspace package does have Systemd
services and that Plasma uses a Systemd based startup approach if available:

Plasma and the systemd startup
https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/

% dpkg -L plasma-workspace | grep "krunner\.service"
/usr/lib/systemd/user/plasma-krunner.service
/usr/share/dbus-1/services/org.kde.krunner.service

I do not have any idea how it is working.

> 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.

Thank you for this explanation. It makes it clear why KRunner has the home
directory as current working directory on Systemd based systems.

Maybe it is a good idea to replicate that for other init based systems.

> 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.

However… I believe there has been another change in Plasma startup since
that time. What I believe was basically a shell script to start up most of
Plasma back then has no become an application written in C++ that at least
is responsible for some of its startup process. But this is from memory and
I am not sure whether it is really accurate.

> 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.

Yes, I understand. So that is another option to consider and discuss
with the alternative init system community.

> 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 systems to complain that adding it has caused a behaviour
> change that breaks their 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).

If it has been like this for about 15 years, then again: Why did it even
work in pre-systemd Debian versions? That is the one question I still do
not know an answer to. Do you have any insight on this?

> > Using X11 still. With Wayland this issue does not happen. But there
> > are 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
> compositors 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.

Honestly I have no idea at all. But Wayland currently is not (yet) my focus.

> > 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 Devuan.

> 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 for 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.

Fair enough, Simon. I informed the other init system community about this
issue and will now wait for feedback from other members of this community.

Maybe a conclusion would be then, to reassign this bug report to another
package or another set of packages. Or maybe we can provide some patch
for you *or* DBUS upstream to consider.

I am also looking into verifying whether the reported issue also happens on
Debian systems. I bet it does.

Thank you again for taking your time for your very thorough and detailed
answer. At this time I do not really expect any further response from you,
except maybe whether you have any idea on why this even worked in pre
systemd times in Debian.

Best,
-- 
Martin