Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
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 ?SMä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. > martin9106 0.0 0.0 6740 2424 ?SMär04 0:00 > /usr/bin/dbus-launch --exit-with-session --sh-syntax > martin9107 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 comparin
Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
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 ?SMär04 0:00 svlogd -tt -b
2048 /var/log/runit/dbus
message+ 2016 0.0 0.0 6536 4896 ?SMär04 0:04 dbus-daemon
--system --nofork --nopidfile
sddm 6587 0.0 0.0 6652 2316 ?SMä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
martin9106 0.0 0.0 6740 2424 ?SMär04 0:00
/usr/bin/dbus-launch --exit-with-session --sh-syntax
martin9107 0.0 0.0 7096 4696 ?Ss Mär04 0:12
/usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
martin9317 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 aspect
Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
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 it
has been patched in some way, presumably to disable systemd integration but
perhaps for other reasons as well. I don't know what changes have been made
and I cannot confirm that they are all correct.)
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?
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 rlimits)
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 systems
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 /
org.freedesktop.DBus.Peer.Ping
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 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.
> 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
Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
Package: dbus-x11 Version: 1.14.6-1devuan1 Severity: normal X-Debbugs-Cc: mar...@lichtvoll.de Dear Maintainer, Like this: …proc# ls -ld $(pidof krunner)/cwd lrwxrwxrwx 1 USER USER 0 10. Feb 14:26 15116/cwd -> / …proc# ls -ld $(pidof plasmashell)/cwd lrwxrwxrwx 1 USER USER 0 10. Feb 14:27 9191/cwd -> /home/USER This is with /bin/sh pointing to Dash, the user shell is Z-Shell, but I have also seen this on systems where the user shell is Bash. According to pstree krunner's parent process is runit which of course has current working directory pointing to /. Plasmashell instead is going like this ├─runsv(2066)─┬─sddm(2116)─┬ ─sddm-helper(8989)───startplasma-x11(8994)─┬─plasma_session(9056)─┬ This is reported with KDE as: krunner starts applications with cwd "/" with init system other than systemd (openrc, runit, ...) https://bugs.kde.org/432975 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 and Debian users with other init systems can benefit from a solution. 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. Using X11 still. With Wayland this issue does not happen. But there are too many other issues with Wayland still. 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. Also I can at least confirm that the current working directory of kwalletd and kiod5 is also /. I bet those are started by the corresponding service files in /usr/share/dbus-1/services. So it appears to me that this has something do to with how dbus-x11 is handling DBUS services. What also points at this that the issue does not happen with a Wayland session. For Systemd based systems Plasma uses Systemd service files for startup, so dbus-x11 is not involved. Thanks, Martin -- System Information: Debian Release: bookworm/sid APT prefers experimental APT policy: (200, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.2.2-x64v3-xanmod1 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages dbus-x11 depends on: ii dbus-bin 1.14.6-1devuan1 ii dbus-daemon 1.14.6-1devuan1 ii dbus-session-bus-common 1.14.6-1devuan1 ii libc62.36-8 ii libdbus-1-3 1.14.6-1devuan1 ii libx11-6 2:1.8.4-2 dbus-x11 recommends no packages. dbus-x11 suggests no packages. -- debconf-show failed
