Hi Simon and Lorenzo. First off: Kudos and appreciation that you took the time to respond this thoroughly. Thank you!
Dear Lorenzo, I am also CC'ing you since some of the findings may point at that it may make sense to resolve this within the runit-services package. However I am certainly not sure yet about that. Especially as it would require a solution for other init systems than Runit as well. Indeed there are several options to fix the issue that Simon outlined. One of them would involve upstream activity in KDE. And another one could probably work from dbus-x11. So much choice to get a clue about! Simon McVittie - 05.03.23, 12:58:48 CET: > On Sun, 05 Mar 2023 at 09:33:08 +0100, Martin wrote: > > This is with Devuan Ceres with Runit and Elogind. I am reporting […] > This bug tracking system is for Debian, not Devuan. Is this > reproducible on a Debian system with elogind, KDE and some > non-systemd init system, perhaps by using a virtual machine? I appreciate that. And I admit I did not yet test it in Debian. I consider setting up a virtual machine to make sure. > (In particular, I am not responsible for decisions made by the Devuan > maintainers of dbus. The version number 1.14.6-1devuan1 indicates that Fair enough! I could install the Debian Experimental version of the package, but that still would not make this Devuan installation a Debian, so rather going for the virtual machine approach. > In my experience, sysv-rc and openrc (sysvinit as process 1) are > generally better-integrated in Debian than runit. Is this > reproducible with sysv-rc or openrc? Lorenzo confirmed this for SysVInit as well: https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2023-February/005929.html I asked for confirmation whether this confirmation is from a Devuan or a Debian based system. Also the KDE bug report I mentioned that this happens across distributions and across different init systems¹. It originally has been reported for Gentoo. [1] https://bugs.kde.org/432975 > How is your `dbus-daemon --session` process started? Is it started by > /etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching? > What is its current working directory? I bet you mean the dbus service which DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/dbus-uwFj[…],guid=9aaf[…]' refers to. According to lsof this is running as PID 9107 currently. Its parent process is runit. Its working directory is "/". It seems to be run with: % cat run #!/usr/bin/env /lib/runit/invoke-run #Copyright: 2022-2023 Lorenzo Puliti <[…]> #License: CC0-1.0 exec 2>&1 if [ ! -d /var/run/dbus ]; then install -d /var/run/dbus -o messagebus -g messagebus fi mountpoint -q /proc/ || exit 162 if [ -x /usr/bin/dbus-uuidgen ]; then /usr/bin/dbus-uuidgen --ensure fi if [ -e /etc/runit/verbose ]; then echo "invoke-run: starting ${PWD##*/}" fi exec dbus-daemon --system --nofork --nopidfile Well I bet basically that would explain its current working directory being "/". However it would not explain it for a SysVInit based system. Also above runit service comes from the runit-services package and the issue has been already there before Lorenzo brought this package into Debian and before I had it installed. Grepping for processes with dbus in their name or arguments also reveals one dbus service that appears to have been launched by sddm which is the display manager I use: % ps aux | grep "[d]bus" root 1991 0.0 0.0 2344 1268 ? Ss Mär04 0:00 runsv dbus root 1992 0.0 0.0 2344 1368 ? Ss Mär04 0:00 runsv dbus.dep-fixer _runit-+ 2015 0.0 0.0 2492 1452 ? S Mär04 0:00 svlogd -tt -b 2048 /var/log/runit/dbus message+ 2016 0.0 0.0 6536 4896 ? S Mär04 0:04 dbus-daemon --system --nofork --nopidfile sddm 6587 0.0 0.0 6652 2316 ? S Mär04 0:00 dbus-launch --autolaunch 3d6f92a09aa53b38614887db63ce99a6 --binary-syntax --close-stderr sddm 6614 0.0 0.0 4404 2128 ? Ss Mär04 0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session martin 9106 0.0 0.0 6740 2424 ? S Mär04 0:00 /usr/bin/dbus-launch --exit-with-session --sh-syntax martin 9107 0.0 0.0 7096 4696 ? Ss Mär04 0:12 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session martin 9317 0.0 0.0 234536 25088 ? Sl Mär04 0:03 /usr/bin/gmenudbusmenuproxy The working directory of PID 6614 is also /. I bet it is not related to the bug I reported. It seems to be a special dbus service just for the display manager and "/" as working directory may just be about right for that one. > /etc/X11/Xsession.d/75dbus_dbus-launch is the way dbus-daemon is meant > to be started on most Debian-derived systems that are not using > `systemd --user`. It starts the `dbus-daemon --session` as part of X > session startup, inheriting its current working directory and various > other aspects of its execution environment (such as rlimits) from the > X session startup scripts. I do have "/etc/X11/Xsession.d/75dbus_dbus-launch" on my system. But no idea whether it is being used to start DBUS or not. To me currently it appears that Runit is starting it. > X11 autolaunching is the way `dbus-daemon --session` was traditionally > started on systems that are less well-integrated than Debian (the […] > I'm considering disabling X11 autolaunching in the Debian packaging of > dbus for Debian 13, since in practice its main function on modern […] > Of course, if I do that, the Devuan maintainers of dbus could revert > that change if they want to, at their own risk. Thank you for all that insight. I hope other members of the alternative init systems community within Debian (some of which are also working for Devuan) can chime in on this. > > Without > > > > % cat /usr/share/dbus-1/services/org.kde.krunner.service > > [D-BUS Service] > > Name=org.kde.krunner > > Exec=/usr/bin/krunner > > SystemdService=plasma-krunner.service > > > > (file is from package plasma-workspace) > > > > KRunner is not started at all. > > I don't use Plasma myself, so I don't know what krunner is or what it > does. Having it be an autostarted D-Bus session service (which means > it won't start if that file is removed) seems like an entirely > reasonable design choice. Sure. I was not questioning that. I just remember that in pre-systemd times in Debian there has not been the issue of KRunner and various other parts of Plasma running as processes with current working directory "/". I am still trying to understand why that is and what would be the best solution to fix that. Preferably with one nicely maintainable fix which works for all the init systems. I understand that this is far away from your primary concern as the default in Debian is Systemd. KRunner is invoked by Alt-Space key combination. Then you just enter some command, application name or something that one of the KRunner plugins understand like "1 EUR in USD". Then it presents some answers that the user can select for the appropriate action to be taken. Or it just shares some information. Maybe call it a more sophisticated quick application runner. Result of it having "/" as a working directory is that any application started by it will also have "/" as working directory. Which is inconvenient when a user chooses to save a file to a certain location as the file dialog then starts from "/". Unless the application itself is using a different default that is. > D-Bus does not document any particular guarantees about the current > working directory for session services. If it is functionally > important for krunner to have its current working directory equal to > the user's home directory, then I would have expected that krunner > should set that up for itself during startup, with something like > (untested, I don't know Qt): > > if (!QDir::setCurrent(QDir::homePath())) { > qWarning("unable to chdir to home directory"); > } > > which would make it independent of how a parent process happens to > have run it. In particular, that would make the behaviour of krunner > when run from your shell during debugging more similar to its > behaviour when started as a D-Bus or systemd service. Thank you. That could also be an option to suggest to upstream. Would wait for feedback by other members of the other init community before probably suggesting that to upstream. > > According to pstree krunner's parent process is runit which of > > course has current working directory pointing to /. > > If krunner's parent process is process 1, I would expect that it has > been run from somewhere else in the process hierarchy and > "daemonized", rather than having been started as a direct child of > process 1, so that doesn't necessarily mean anything. Sure. > > For Systemd based systems Plasma uses Systemd service files for > > startup, so dbus-x11 is not involved. > > I think this indicates a misunderstanding of how this works and what > dbus-x11 does. dbus-x11 is never *directly* involved in how a D-Bus > service is started. However, it is *indirectly* involved, because > dbus-x11 is responsible for launching the `dbus-daemon --session` > process, and it is the `dbus-daemon --session` process that is > responsible for starting D-Bus session services like krunner. I just referred to that the plasma-workspace package does have Systemd services and that Plasma uses a Systemd based startup approach if available: Plasma and the systemd startup https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ % dpkg -L plasma-workspace | grep "krunner\.service" /usr/lib/systemd/user/plasma-krunner.service /usr/share/dbus-1/services/org.kde.krunner.service I do not have any idea how it is working. > For a D-Bus session service like krunner with SystemdService= in its > D-Bus .service file, on systemd-based systems with dbus-user-session > installed, the dbus-daemon asks `systemd --user` via IPC to start the > corresponding systemd service. The dbus-daemon and krunner will both > be systemd user services, therefore they will both have the home > directory as current working directory unless specifically configured > otherwise, because systemd documents that behaviour. Thank you for this explanation. It makes it clear why KRunner has the home directory as current working directory on Systemd based systems. Maybe it is a good idea to replicate that for other init based systems. > On a non-systemd-based system, when not using dbus-user-session, or > for a session service that does not have a corresponding > SystemdService, the dbus-daemon forks and execs the service as a > child process (or it might be a "daemonized" grandchild process, it's > a while since I looked at that code path). The session service will > probably inherit the dbus-daemon's current working directory, > whatever that happens to be. I just wonder how that worked out in pre-systemd times in Debian. Cause KRunner definitely did not have "/" as its current working directory at the time. However… I believe there has been another change in Plasma startup since that time. What I believe was basically a shell script to start up most of Plasma back then has no become an application written in C++ that at least is responsible for some of its startup process. But this is from memory and I am not sure whether it is really accurate. > A possible way to address this would be for either dbus-launch or > `dbus-daemon --session` to explicitly chdir() to the home directory > during its startup, which would bring the non-systemd code path one > step closer to being like the systemd code path. Yes, I understand. So that is another option to consider and discuss with the alternative init system community. > However, the way that this whole code path works is the same way it > has worked for about 15 years, so my main concern about adding an > explicit chdir() would be whether it will cause other users of > non-systemd systems to complain that adding it has caused a behaviour > change that breaks their workflow. Users of "more traditional" code > paths and components such as non-systemd init systems are often using > those code paths because they don't want behaviour changes, so the > desired maintenance model for those code paths is often "don't touch > anything unless absolutely necessary", particularly if they are > poorly-understood upstream (definitely the case for dbus-launch, > which is mostly 15 year old legacy code). If it has been like this for about 15 years, then again: Why did it even work in pre-systemd Debian versions? That is the one question I still do not know an answer to. Do you have any insight on this? > > Using X11 still. With Wayland this issue does not happen. But there > > are too many other issues with Wayland still. > > I don't know how startup of the D-Bus session bus under Wayland on > non-systemd systems is meant to work. As far as I know, Wayland > compositors don't generally run /etc/X11/Xsession.d (or at least, > GNOME doesn't). Honestly I'm a little surprised if it does work: I > would generally have expected Wayland systems to be relying on > dbus-user-session, which is currently only implemented for systemd > systems. Honestly I have no idea at all. But Wayland currently is not (yet) my focus. > > In case you are not willing to look into this issue please tell, so > > another solution or workaround can be found. I will also report > > this in Devuan. > I'd consider patches if a patch is proposed, but I am not in a > position to spend a lot of time on researching non-default init > systems, or on researching whether a proposed patch will have > unintended consequences for a different non-default init system. > Please reach consensus on what the non-systemd community wants, and > then propose a change in dbus upstream if appropriate. Fair enough, Simon. I informed the other init system community about this issue and will now wait for feedback from other members of this community. Maybe a conclusion would be then, to reassign this bug report to another package or another set of packages. Or maybe we can provide some patch for you *or* DBUS upstream to consider. I am also looking into verifying whether the reported issue also happens on Debian systems. I bet it does. Thank you again for taking your time for your very thorough and detailed answer. At this time I do not really expect any further response from you, except maybe whether you have any idea on why this even worked in pre systemd times in Debian. Best, -- Martin _______________________________________________ Pkg-utopia-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
