Devuan bug report logs - #745
dbus-x11: Several processes in Plasma session including krunner have / as current working directory

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

Package: dbus-x11
Version: 1.14.6-1devuan1
Severity: normal
X-Debbugs-Cc: Martin@Lichtvoll.de

Dear Maintainer,

I also reported this to Debian as https://bugs.debian.org/1032368

What follows is the text I sent to Debian BTS:



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:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 5 (daedalus/ceres)
Release:	5
Codename:	daedalus ceres
Architecture: x86_64

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  libc6                    2.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
-- 
Martin

Message #8 received at 745@bugs.devuan.org (full text, mbox, reply):

Control: forwarded -1  https://bugs.debian.org/1032368

Martin,

Thanks for this.

On Sun, Mar 05, 2023 at 09:59:35AM +0100, Martin Steigerwald wrote:
> Package: dbus-x11
> Version: 1.14.6-1devuan1
> Severity: normal
> X-Debbugs-Cc: Martin@Lichtvoll.de
> 
> Dear Maintainer,
> 
> I also reported this to Debian as

Simon McVittie's is, of course, correct that src:dbus being forked in Devuan
means this should be dealt with in Devuan. Notwithstanding that, I am very
grateful for his thorough, considered and illuminating reply. The same behaviour
is evident in a non-systemd Debian installation.

Like Simon, I have no experience of KDE or krunner. I also agree that legacy
DBus activation appears to be working here as intended and documented, with no
guarantee on the cwd given.

My gut reaction is that this issue is should really be resolved elsewhere. If
it is crucial that krunner uses a particular working directory, then it needs to
chdir() explicitly itself.

I also quite understand his concern that changing the behaviour of DBus may have
unintended consequences and I am certain that changing the behaviour of DBus
during the freeze will not happen. I suppose early in the next cycle is
possible. Simon, might the implications of that be reviewed again upstream? I
found an upstream issue with patch to implement such behaviour that has not been
merged[1].

Thanks

Mark

[1]  https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Message #17 received at 745@bugs.devuan.org (full text, mbox, reply):

Dear Mark.

Thanks for looking at this!

Mark Hindley - 06.03.23, 12:52:08 CET:
> On Sun, Mar 05, 2023 at 09:59:35AM +0100, Martin Steigerwald wrote:
> > Package: dbus-x11
> > Version: 1.14.6-1devuan1
> > Severity: normal
> > X-Debbugs-Cc: Martin@Lichtvoll.de
> > 
> > Dear Maintainer,
> > 
> > I also reported this to Debian as
> 
> Simon McVittie's is, of course, correct that src:dbus being forked in
> Devuan means this should be dealt with in Devuan. Notwithstanding
> that, I am very grateful for his thorough, considered and
> illuminating reply. The same behaviour is evident in a non-systemd
> Debian installation.

Yeah. Lorenzo confirmed this as well. He was able to replicate the issue 
on a Debian installation.

> Like Simon, I have no experience of KDE or krunner. I also agree that
> legacy DBus activation appears to be working here as intended and
> documented, with no guarantee on the cwd given.

Again: it is a kind of quick application starter. You press Alt-Space, 
enter something, it offers a variety of matches, you select one and press 
enter or just press enter to use the first match and that's it. If 
krunner's pwd is "/" then the application it started usually also has 
"/". Which means any file dialog started from it will have "/".

Additionally meanwhile I found that when I print a web site to PDF in 
Firefox the file dialog also starts with "/". This could be due to

export GTK_USE_PORTAL=1

in order to use KDE based file dialog with Firefox and other apps that 
use GTK.

None of this breaks the system. It just makes it more cumbersome to use.

I also wonder whether only Plasma desktop is affected.

> My gut reaction is that this issue is should really be resolved
> elsewhere. If it is crucial that krunner uses a particular working
> directory, then it needs to chdir() explicitly itself.

I understand. I  add this this suggestion to the KDE bug report. However 
as noted above: Besides KRunner some other processes appear to be 
affected. So it would be required to file an upstream report with any of 
those affected components. Might be the cleanest approach still. 
Especially as long as there are no guarantees.

I always thought that anything within a user session is using $HOME as 
pwd, but apparently that does not seem to be guaranteed or documented. 
And it may have been like that back in the days where almost everything 
related to a user desktop session was started from one place that 
started out from $HOME and all the child processes inherited pwd from 
that place.

It appears that for systems with other init systems there does not seem 
to be a consistent approach to handle this.

> I also quite understand his concern that changing the behaviour of
> DBus may have unintended consequences and I am certain that changing
> the behaviour of DBus during the freeze will not happen. I suppose
> early in the next cycle is possible. […]

Sure.

As I think that Simon is right and it is indeed is "/etc/X11/Xsession.d/
75dbus_dbus-launch" that started the session dbus. I mismatched the 
arguments and while I saw a third DBUS running under the user 
"messagebus" I did not make the connection that this is the one that is 
started by the runit service dir.

So my next approach would be to play around with "/etc/X11/Xsession.d/
75dbus_dbus-launch". First step would be to figure out whether "$HOME" is 
set to the session user home directory in that script. If yes, I'd try 
changing working directory to $HOME. If not… I am not sure, I may still 
go for changing pwd to the home directory of the main user of my system 
to actually verify whether this would be working as a work-around.

Will report back once I know more.

> Simon, might the implications of that be reviewed again upstream? I 
> found an upstream issue with patch to implement such behaviour that 
> has not been merged[1].

Interesting. That is from 4 years ago already.

> [1]  https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Thanks,
-- 
Martin

Message #22 received at 745@bugs.devuan.org (full text, mbox, reply):

Control: forwarded -1 https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

On Mon, 06 Mar 2023 at 11:52:08 +0000, Mark Hindley wrote:
> Simon, might the implications of that be reviewed again upstream? I
> found an upstream issue with patch to implement such behaviour that has not been
> merged <https://gitlab.freedesktop.org/dbus/dbus/-/issues/214>.

I had completely forgotten about that issue report. At least I'm
consistent: 4 years ago, I also said something along the lines of "maybe,
but I'm concerned that this is going to break someone's workflow". If
there is consensus even among the users of highly change-averse
distributions that $HOME is a better working directory than /, then maybe
this can/should change in the dbus 1.15.x and Debian-13-as-testing cycle.

As you said, during the Debian 12 freeze is not the time to change this.
dbus 1.16.0 would be the earliest stable release of dbus that is likely
to have this behaviour change upstream, although obviously Devuan is
already patching the dbus package and is free to backport whatever
changes they are willing to take responsibility for.

What I absolutely don't want is to make the change, and then 2 years
later get hate mail from someone telling me that I've broken their
system by making dbus-launch prevent /home from being unmounted and
"why can't you just" add an option to use daemon(3).

Because the recommended and most-common way to run the session bus in
2023 is via the dbus.service managed by `systemd --user` (that's the
dbus-user-session package in Debian), it is primarily users of more
traditional system configurations (sysv-rc or similar, X11, dbus-x11,
dbus-launch) that will be affected by this. I do not have enough time
available for dbus to carry out testing on arbitrary OS configurations,
and I am not able to take responsibility for researching whether this
will break anyone's use-case. It's up to the people who maintain those
more traditional system configurations to tell me whether dbus/dbus#214
is what you want or not.

Because dbus-launch is already poorly-understood spaghetti code, I
specifically don't want this to be a configuration option: it should
either always use $HOME as in David King's proposed patch, or always use
"/" as it does in 1.14.x. Having two rarely-tested code paths is worse
than having one.

    smcv

Message #29 received at 745@bugs.devuan.org (full text, mbox, reply):

Simon,

Thanks.

On Mon, Mar 06, 2023 at 03:25:18PM +0000, Simon McVittie wrote:
> What I absolutely don't want is to make the change, and then 2 years
> later get hate mail from someone telling me that I've broken their
> system by making dbus-launch prevent /home from being unmounted and
> "why can't you just" add an option to use daemon(3).

I think that is a very good point.

KDE is the only area where I have heard of this causing problems and I am not
aware of any other reports that seem to have the same underlying cause. I am not
convinced there *is* a consensus for change and the risk of changing the default
for all users of legacy DBus activation seems high.

Martin, I still think this is for KDE to address if it is important to them. I
don't think I would push to change the behaviour of DBus in either Debian or
Devuan at the moment.

Best wishes

Mark

Message #34 received at 745@bugs.devuan.org (full text, mbox, reply):

Mark and Simon: thank you.

Mark Hindley - 06.03.23, 17:22:12 CET:
> On Mon, Mar 06, 2023 at 03:25:18PM +0000, Simon McVittie wrote:
> > What I absolutely don't want is to make the change, and then 2 years
> > later get hate mail from someone telling me that I've broken their
> > system by making dbus-launch prevent /home from being unmounted and
> > "why can't you just" add an option to use daemon(3).
> 
> I think that is a very good point.
> 
> KDE is the only area where I have heard of this causing problems and I
> am not aware of any other reports that seem to have the same
> underlying cause. …

The upstream issue¹ refers to GNOME applications in RHEL 7 being 
affected. RHEL 7 would have a KDE without Systemd startup I bet².

[1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

[2] https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ (however I am not entirely sure whether that kind of startup is 
activated by default nowadays)

> I am not convinced there *is* a consensus for change and the risk of 
> changing the default for all users of legacy DBus activation seems 
> high.

Fair enough.

> Martin, I still think this is for KDE to address if it is important to
> them. I don't think I would push to change the behaviour of DBus in
> either Debian or Devuan at the moment.

I added that information and suggestion to the KDE bug report:

krunner starts applications with cwd "/" with init system other than 
systemd (openrc, runit, ...)
https://bugs.kde.org/show_bug.cgi?id=432975#c16

Let's see whether KDE developers are open to make the required changes.

Thanks,
-- 
Martin

Message #39 received at 745@bugs.devuan.org (full text, mbox, reply):

Mark Hindley - 06.03.23, 17:22:12 CET:
> On Mon, Mar 06, 2023 at 03:25:18PM +0000, Simon McVittie wrote:
> > What I absolutely don't want is to make the change, and then 2 years
> > later get hate mail from someone telling me that I've broken their
> > system by making dbus-launch prevent /home from being unmounted and
> > "why can't you just" add an option to use daemon(3).
> 
> I think that is a very good point.

I have thought about this some more and the following question came up: 
Why would dbus-launch with $HOME as current working directory prevent 
from unmounting /home any more than any other process that runs with a 
user session? At least with desktop environments like Plasma and GNOME 
there is a ton of other processes blocking unmounting /home. It could be 
with a very limited environment like with a tiling window manager that 
nothing else would be using $HOME as working directory, but that must be 
a very limited environment then, I'd say. Anyway: There will be no hate 
mail from me. Promised.

I did some more testing which in the end is just a confirmation of what I 
could have known already from the previous discussion. While I did not 
confirm the PID of the dbus-launch process started by the "75dbus_dbus-
launch" script it also pretty much confirms that the session DBUS is 
started by that script.

I added

date >/tmp/dbus-launch-started
echo $HOME >/tmp/dbus-launch-home
pwd >/tmp/dbus-launch-pwd

to "/etc/X11/Xsession.d/75dbus_dbus-launch" and

date >/tmp/dbus-update-env-started
echo $HOME >/tmp/dbus-update-env-home
pwd >/tmp/dbus-update-env-pwd

to "/etc/X11/Xsession.d/95dbus_update-activation-env".

And got this:

% grep . /tmp/dbus-launch-*
/tmp/dbus-launch-home:/home/martin
/tmp/dbus-launch-pwd:/home/martin
/tmp/dbus-launch-started:Di 7. Mär 18:02:12 CET 2023

% grep . /tmp/dbus-update-env-*
/tmp/dbus-update-env-home:/home/martin
/tmp/dbus-update-env-pwd:/home/martin
/tmp/dbus-update-env-started:Di 7. Mär 18:02:12 CET 2023

So both are started and both have the right working directory and $HOME 
set to the user starting the X session.

So it is really that chdir("/") in dbus-launch¹ that causes the issue at 
hand and thus there is no way to globally work-around the issue I 
reported, at least not short of recompiling dbus-launch without that 
chdir in place. Actually that is the result that was to be expected. But 
now I confirmed it. I'd wonder that anyone who would really like to have 
the option to have "dbus-launch" as started by "75dbus_dbus-launch" 
having "/" as current working directory could just change the script, 
given the chdir("/") would be patched out of dbus-launch.

[1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Interestingly in "/etc/X11/Xsession.d/95dbus_update-activation-env" 
there is:

  # Note that anything that is D-Bus-activated between here and
  # 95dbus_update-activation-env will not have the complete environment
  # set up by Xsession.d, unless the Xsession.d snippet that sets the
  # environment variable also calls dbus-update-activation-environment.
  # See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815503>

but there are only "90gpg-agent" and "90x11-common_ssh-agent" between 
it. So it seems to be whatever "95dbus_update-activation-env" is doing 
does not including telling dbus-launch to switch working directory to 
$HOME. But at least with anything started through krunner $HOME is set 
correctly to the users home directory.

> KDE is the only area where I have heard of this causing problems and I
> am not aware of any other reports that seem to have the same
> underlying cause. I am not convinced there *is* a consensus for
> change and the risk of changing the default for all users of legacy
> DBus activation seems high.
> 
> Martin, I still think this is for KDE to address if it is important to
> them. I don't think I would push to change the behaviour of DBus in
> either Debian or Devuan at the moment.

So I really hope that KDE developers are willing to make a change. Of 
course they could argue, that it worked before…

Until then I have a workaround for KRunner (a desktop file in Autostart) 
and also one for XDG KDE portal.

It appears to me that in

% cat /usr/share/dbus-1/services/
org.freedesktop.impl.portal.desktop.kde.service
[D-BUS Service]
Name=org.freedesktop.impl.portal.desktop.kde
Exec=/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
SystemdService=plasma-xdg-desktop-portal-kde.service

as well as

% 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

there is no provision to change the working directory for the started 
DBUS service. At least I found no documentation of the specification of 
those DBUS service files.

Something like

sh -c "cd $HOME; /usr/bin/krunner"

resulted in not starting the program at all.

I still found a work-around for the desktop portal, but it is not really 
nice. I added the following as an autostart script to "~/.config/
autostart":

-----------------------------------------------------------------------

#!/bin/sh

cd $HOME

killall -u martin -e /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-
portal-kde
/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde &>/dev/null &

cd -

-----------------------------------------------------------------------

This works as long as the process is running. In case I quit it again, 
its autostarted again as a DBUS service and its current working 
directory again points to "/". I consider opening a bug report for the
XDG KDE desktop portal as well.

Best,
-- 
Martin

Send a report that this bug log contains spam.