Mark Hindley - 06.03.23, 17:22:12 CET: > On Mon, Mar 06, 2023 at 03:25:18PM +0000, Simon McVittie wrote: > > What I absolutely don't want is to make the change, and then 2 years > > later get hate mail from someone telling me that I've broken their > > system by making dbus-launch prevent /home from being unmounted and > > "why can't you just" add an option to use daemon(3). > > I think that is a very good point.
I have thought about this some more and the following question came up: Why would dbus-launch with $HOME as current working directory prevent from unmounting /home any more than any other process that runs with a user session? At least with desktop environments like Plasma and GNOME there is a ton of other processes blocking unmounting /home. It could be with a very limited environment like with a tiling window manager that nothing else would be using $HOME as working directory, but that must be a very limited environment then, I'd say. Anyway: There will be no hate mail from me. Promised. I did some more testing which in the end is just a confirmation of what I could have known already from the previous discussion. While I did not confirm the PID of the dbus-launch process started by the "75dbus_dbus- launch" script it also pretty much confirms that the session DBUS is started by that script. I added date >/tmp/dbus-launch-started echo $HOME >/tmp/dbus-launch-home pwd >/tmp/dbus-launch-pwd to "/etc/X11/Xsession.d/75dbus_dbus-launch" and date >/tmp/dbus-update-env-started echo $HOME >/tmp/dbus-update-env-home pwd >/tmp/dbus-update-env-pwd to "/etc/X11/Xsession.d/95dbus_update-activation-env". And got this: % grep . /tmp/dbus-launch-* /tmp/dbus-launch-home:/home/martin /tmp/dbus-launch-pwd:/home/martin /tmp/dbus-launch-started:Di 7. Mär 18:02:12 CET 2023 % grep . /tmp/dbus-update-env-* /tmp/dbus-update-env-home:/home/martin /tmp/dbus-update-env-pwd:/home/martin /tmp/dbus-update-env-started:Di 7. Mär 18:02:12 CET 2023 So both are started and both have the right working directory and $HOME set to the user starting the X session. So it is really that chdir("/") in dbus-launch¹ that causes the issue at hand and thus there is no way to globally work-around the issue I reported, at least not short of recompiling dbus-launch without that chdir in place. Actually that is the result that was to be expected. But now I confirmed it. I'd wonder that anyone who would really like to have the option to have "dbus-launch" as started by "75dbus_dbus-launch" having "/" as current working directory could just change the script, given the chdir("/") would be patched out of dbus-launch. [1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214 Interestingly in "/etc/X11/Xsession.d/95dbus_update-activation-env" there is: # Note that anything that is D-Bus-activated between here and # 95dbus_update-activation-env will not have the complete environment # set up by Xsession.d, unless the Xsession.d snippet that sets the # environment variable also calls dbus-update-activation-environment. # See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815503> but there are only "90gpg-agent" and "90x11-common_ssh-agent" between it. So it seems to be whatever "95dbus_update-activation-env" is doing does not including telling dbus-launch to switch working directory to $HOME. But at least with anything started through krunner $HOME is set correctly to the users home directory. > KDE is the only area where I have heard of this causing problems and I > am not aware of any other reports that seem to have the same > underlying cause. I am not convinced there *is* a consensus for > change and the risk of changing the default for all users of legacy > DBus activation seems high. > > Martin, I still think this is for KDE to address if it is important to > them. I don't think I would push to change the behaviour of DBus in > either Debian or Devuan at the moment. So I really hope that KDE developers are willing to make a change. Of course they could argue, that it worked before… Until then I have a workaround for KRunner (a desktop file in Autostart) and also one for XDG KDE portal. It appears to me that in % cat /usr/share/dbus-1/services/ org.freedesktop.impl.portal.desktop.kde.service [D-BUS Service] Name=org.freedesktop.impl.portal.desktop.kde Exec=/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde SystemdService=plasma-xdg-desktop-portal-kde.service as well as % cat /usr/share/dbus-1/services/org.kde.krunner.service [D-BUS Service] Name=org.kde.krunner Exec=/usr/bin/krunner SystemdService=plasma-krunner.service there is no provision to change the working directory for the started DBUS service. At least I found no documentation of the specification of those DBUS service files. Something like sh -c "cd $HOME; /usr/bin/krunner" resulted in not starting the program at all. I still found a work-around for the desktop portal, but it is not really nice. I added the following as an autostart script to "~/.config/ autostart": ----------------------------------------------------------------------- #!/bin/sh cd $HOME killall -u martin -e /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop- portal-kde /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde &>/dev/null & cd - ----------------------------------------------------------------------- This works as long as the process is running. In case I quit it again, its autostarted again as a DBUS service and its current working directory again points to "/". I consider opening a bug report for the XDG KDE desktop portal as well. Best, -- Martin