On Sun, 05 Mar 2023 at 15:49:51 +0100, Martin Steigerwald wrote: > Simon McVittie - 05.03.23, 12:58:48 CET: > > How is your `dbus-daemon --session` process started? Is it started by > > /etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching? > > What is its current working directory? > > It seems to be run with: > > % cat run > #!/usr/bin/env /lib/runit/invoke-run > #Copyright: 2022-2023 Lorenzo Puliti <[…]>
This script does not start a session bus (notice the --system argument and the absence of a --session argument): > exec dbus-daemon --system --nofork --nopidfile so it would be incorrect for $DBUS_SESSION_BUS_ADDRESS to point to the socket it is listening on (which should be /run/dbus/system_bus_socket rather than /tmp/anything). This looks like a runit-specific script to start the *system* bus: a runit equivalent of the /lib/systemd/system/dbus.service and /etc/init.d/dbus in the dbus package. The system bus, `dbus-daemon --system`, is a system-wide bus (one per machine) for system services like elogind, polkit and NetworkManager. The session bus, `dbus-daemon --session`, is a per-session bus (one per X11 session or one per (machine,uid) pair) for per-user services like kwallet. They're implemented by running the same code with different configuration, but they are not interchangeable. Practical desktop systems need both. > % ps aux | grep "[d]bus" If you were using systemd I'd suggest using systemd-cgls to get a logical overview of how the various processes in the system fit together. There's an obvious flaw in that suggestion for a runit user, but perhaps the non-default-init community has something equivalent that can keep track of how processes relate to each other even in the presence of daemonization? > sddm 6587 0.0 0.0 6652 2316 ? 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 You are correct to say that those two are unlikely to be involved in the issue you reported, because this is the per-user or per-X11-display session bus for uid "sddm", and is not involved with the management of per-user processes for uid "martin". The arguments passed to sddm's dbus-launch are consistent with it having been started by X11 autolaunching by some sddm component. I suspect that this means sddm's login screen is implemented as a miniature version of an ordinary X11 GUI session, with some special settings to make it behave differently. It's a reasonable design to use, and the "greeter" in GNOME's gdm behaves similarly. > 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 *Those* look like the implementation of your per-user or per-X11-display session bus for uid "martin". I can't tell how they were started (and it's up to you to find out), but the arguments that were passed to dbus-launch are the same ones it would get from /etc/X11/Xsession.d/75dbus_dbus-launch, and the consecutive process IDs are reasonably strong evidence that dbus-daemon process 9107 was started by dbus-launch process 9106 (or at least around the same time). /etc/X11/Xsession.d/75dbus_dbus-launch inherits its execution environment from whatever component runs the Xsession script (often a display manager, and in your case presumably sddm). If you want "session stuff" to be started with your home directory as the current working directory, then making sure the Xsession script runs with that same working directory is a good idea. Editing or adding some scripts in Xsession.d so they write their current working directory and other relevant information to the system log using logger(1) might be a good direction for debugging this. > > On a non-systemd-based system, when not using dbus-user-session, or > > for a session service that does not have a corresponding > > SystemdService, the dbus-daemon forks and execs the service as a > > child process (or it might be a "daemonized" grandchild process, it's > > a while since I looked at that code path). The session service will > > probably inherit the dbus-daemon's current working directory, > > whatever that happens to be. > > I just wonder how that worked out in pre-systemd times in Debian. Cause > KRunner definitely did not have "/" as its current working directory at the > time. Perhaps you could bring up a pre-systemd Debian system (wheezy or older) in a VM, and find out? An older live-CD image is probably the easiest way, since that avoids the need to have a working mirror for EOL suites that were moved to archive.debian.org already. (Of course, pre-systemd Debian systems booted with sysv-rc and sysvinit, so comparing them to modern Debian with sysv-rc and sysvinit would involve fewer variables than Devuan with runit.) smcv