Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
42 views
Skip to first unread message
Martin
Mar 5, 2023, 3:40:04 AM3/5/23
to
Package: dbus-x11
Version: 1.14.6-1devuan1
Severity: normal
X-Debbugs-Cc: Mar...@Lichtvoll.de
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, ...)
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 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 Steigerwald
Mar 5, 2023, 4:20:04 AM3/5/23
to
dbus-x11: Several processes in Plasma session including krunner have /
as current working directory
https://bugs.devuan.org/745
--
Martin
as current working directory
https://bugs.devuan.org/745
--
Martin
Simon McVittie
Mar 5, 2023, 7:10:04 AM3/5/23
to
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
> 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
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.
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 /.
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.
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.
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 that
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 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).
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 are
> too many other issues with Wayland still.
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.
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 Devuan.
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.
smcv
Martin Steigerwald
Mar 5, 2023, 10:00:05 AM3/5/23
to
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:
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
[…]
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
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 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
> reproducible on a Debian system with elogind, KDE and some
> non-systemd init system, perhaps by using a virtual machine?
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
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?
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?
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.
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
[…]
> 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
> that change if they want to, at their own risk.
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.
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.
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.
> > 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.
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.
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.
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.
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).
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.
> > 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.
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
Simon McVittie
Mar 5, 2023, 12:20:04 PM3/5/23
to
On Sun, 05 Mar 2023 at 15:49:51 +0100, Martin Steigerwald wrote:
> Simon McVittie - 05.03.23, 12:58:48 CET:
> 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?
>
> > /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
>
> % cat run
> #!/usr/bin/env /lib/runit/invoke-run
> #Copyright: 2022-2023 Lorenzo Puliti <[…]>
the absence of a --session argument):
> exec dbus-daemon --system --nofork --nopidfile
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"
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
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
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.
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
Mark Hindley
Mar 6, 2023, 8:00:03 AM3/6/23
to
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: Mar...@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
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: Mar...@Lichtvoll.de
>
> Dear Maintainer,
>
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
Martin Steigerwald
Mar 6, 2023, 9:50:04 AM3/6/23
to
Dear Mark.
Thanks for looking at this!
Mark Hindley - 06.03.23, 12:52:08 CET:
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
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: Mar...@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
> > Package: dbus-x11
> > Version: 1.14.6-1devuan1
> > Severity: normal
> > X-Debbugs-Cc: Mar...@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.
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.
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.
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
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].
> [1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214
Thanks,
--
Martin
Simon McVittie
Mar 6, 2023, 10:30:04 AM3/6/23
to
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
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
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
Mark Hindley
Mar 6, 2023, 11:30:04 AM3/6/23
to
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
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).
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
Martin Steigerwald
Mar 6, 2023, 1:30:04 PM3/6/23
to
Mark and Simon: thank you.
Mark Hindley - 06.03.23, 17:22:12 CET:
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
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. …
> > 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
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.
> 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.
krunner starts applications with cwd "/" with init system other than
systemd (openrc, runit, ...)
Let's see whether KDE developers are open to make the required changes.
Thanks,
--
Martin
Martin Steigerwald
Mar 7, 2023, 2:30:04 PM3/7/23
to
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:
> > 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.
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.
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
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
0 new messages