On Sun, 05 Mar 2023 at 09:33:08 +0100, Martin wrote: > This is with Devuan Ceres with Runit and Elogind. I am reporting this > with Debian as well, cause I think it is an issue in Debian as well
This bug tracking system is for Debian, not Devuan. Is this reproducible on a Debian system with elogind, KDE and some non-systemd init system, perhaps by using a virtual machine? (In particular, I am not responsible for decisions made by the Devuan maintainers of dbus. The version number 1.14.6-1devuan1 indicates that it has been patched in some way, presumably to disable systemd integration but perhaps for other reasons as well. I don't know what changes have been made and I cannot confirm that they are all correct.) In my experience, sysv-rc and openrc (sysvinit as process 1) are generally better-integrated in Debian than runit. Is this reproducible with sysv-rc or openrc? How is your `dbus-daemon --session` process started? Is it started by /etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching? What is its current working directory? /etc/X11/Xsession.d/75dbus_dbus-launch is the way dbus-daemon is meant to be started on most Debian-derived systems that are not using `systemd --user`. It starts the `dbus-daemon --session` as part of X session startup, inheriting its current working directory and various other aspects of its execution environment (such as rlimits) from the X session startup scripts. X11 autolaunching is the way `dbus-daemon --session` was traditionally started on systems that are less well-integrated than Debian (the classic use-case is something like "I want to run Firefox under twm on Solaris"). In X11 autolaunching, dbus-launch is started as a daemonized child process of whatever arbitrary process happens to have been the first one to use D-Bus, which means it will inherit its current working directory and other aspects of its execution environment (such as rlimits) from that arbitrary process. This is obviously not good, because the dbus-daemon should have a predictable execution environment, but it's also not really fixable within X11 autolaunching because of the way it works. I would consider most problems with X11 autolaunching to be "won't fix" as a result, because their best solution will be to start the session dbus-daemon during X session startup instead, either one per X11 display with /etc/X11/Xsession.d/75dbus_dbus-launch, or one per (machine,uid) pair with dbus-user-session (currently only possible on systemd systems because nobody has contributed an implementation of that behaviour for non-systemd). I'm considering disabling X11 autolaunching in the Debian packaging of dbus for Debian 13, since in practice its main function on modern systems is to make error messages more misleading. This would mean that the only ways to get a session bus are /etc/X11/Xsession.d/75dbus_dbus-launch, or dbus-user-session, or a parent process explicitly starting one. Of course, if I do that, the Devuan maintainers of dbus could revert that change if they want to, at their own risk. > Without > > % cat /usr/share/dbus-1/services/org.kde.krunner.service > [D-BUS Service] > Name=org.kde.krunner > Exec=/usr/bin/krunner > SystemdService=plasma-krunner.service > > (file is from package plasma-workspace) > > KRunner is not started at all. I don't use Plasma myself, so I don't know what krunner is or what it does. Having it be an autostarted D-Bus session service (which means it won't start if that file is removed) seems like an entirely reasonable design choice. For comparison, on a test VM with Debian 12 alpha and a mostly-unconfigured Plasma, running on systemd, I do not initially have a krunner process at all. If I force it to be started by running dbus-send --session --dest=org.kde.krunner --print-reply / org.freedesktop.DBus.Peer.Ping then it's run as a systemd "user service" with current working directory = my home directory. D-Bus does not document any particular guarantees about the current working directory for session services. If it is functionally important for krunner to have its current working directory equal to the user's home directory, then I would have expected that krunner should set that up for itself during startup, with something like (untested, I don't know Qt): if (!QDir::setCurrent(QDir::homePath())) { qWarning("unable to chdir to home directory"); } which would make it independent of how a parent process happens to have run it. In particular, that would make the behaviour of krunner when run from your shell during debugging more similar to its behaviour when started as a D-Bus or systemd service. > According to pstree krunner's parent process is runit which of course > has current working directory pointing to /. If krunner's parent process is process 1, I would expect that it has been run from somewhere else in the process hierarchy and "daemonized", rather than having been started as a direct child of process 1, so that doesn't 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. 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. 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. 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. 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. smcv