Hello, I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed. Thanks, Alexey Rochev
On Tue, 23 Oct 2018 22:53:50 -0000 "Alexey Rochev" equeim@gmail.com wrote:
I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed. Thanks, Alexey Rochev
So, I always start X from runlevel 3 (multiuser) using startx. After reading this, I went into the startx script and commented out the unset for DBUS_SESSION_BUS_ADDRESS. I haven't noticed any effects while running X from doing this. I did notice that when I shut down by closing X, and then using shutdown -P now that the powerdown does not work. I have to manually turn the system off, though it does reach shutdown state. Just an additional data point.
I checked in koji, and while the latest version is 1.4, this still remains the same.
One effect of this is for example, is inability to control PulseAudio via D-Bus from X session (although most programs use libpulse API that works via sockets) or lack of access to user D-Bus services (e.g. org.freedesktop.Notifications) from user systemd services. This line was added in pre-systemd times when D-Bus session has been launching together with X server. Now D-Bus is launched by systemd on login, and unsetting DBUS_SESSION_BUS_ADDRESS in startx results in another D-Bus daemon.
On Wed, 24 Oct 2018 15:32:31 -0000 "Alexey Rochev" equeim@gmail.com wrote:
One effect of this is for example, is inability to control PulseAudio via D-Bus from X session (although most programs use libpulse API that works via sockets) or lack of access to user D-Bus services (e.g. org.freedesktop.Notifications) from user systemd services. This line was added in pre-systemd times when D-Bus session has been launching together with X server. Now D-Bus is launched by systemd on login, and unsetting DBUS_SESSION_BUS_ADDRESS in startx results in another D-Bus daemon.
I don't think I have anything like that happening, so that would explain why I am seeing no difference.
You see no difference because not much programs are affected by this (I discovered this issue when I tried to write systemd service that displays notifications via org.freedesktop.Notification D-Bus interface and was unable to get it to work). If you uncomment "unset DBUS_SESSION_BUS_ADDRESS" in /usr/bin/startx, what's the value of it after you started X? What does "ps -ef | grep dbus-daemon" return for you? You can verify that your X session uses different dbus-daemon that systemd by checking the output of "dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames" command. If it doesn't list org.freedesktop.systemd1 or org.pulseaudio.Server you have this issue.
On Wed, 24 Oct 2018 21:16:07 -0000 "Alexey Rochev" equeim@gmail.com wrote:
You can verify that your X session uses different dbus-daemon that systemd by checking the output of "dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames" command. If it doesn't list org.freedesktop.systemd1 or org.pulseaudio.Server you have this issue.
Yes, I have the issue.
On Wed, 24 Oct 2018 07:40:51 -0700 stan stanl-fedorauser@vfemail.net wrote:
I did notice that when I shut down by closing X, and then using shutdown -P now that the powerdown does not work. I have to manually turn the system off, though it does reach shutdown state. Just an additional data point.
That must have been a fluke. My next shutdown powered down, and I tried a few more and they worked as well.
Hi,
On 24-10-18 00:53, Alexey Rochev wrote:
Hello, I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed.
I'm going over my backlog of things to respond to, even though this mail was send a over a year ago this seems worthwhile to respond too.
I've currently re-opened the discussion about this here: https://gitlab.freedesktop.org/xorg/app/xinit/issues/9
Hopefully we can get some momentum on getting this fixed there.
Regards,
Hans
On Sunday, 18 August 2019 at 14:51, Hans de Goede wrote:
On 24-10-18 00:53, Alexey Rochev wrote:
Hello, I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed.
I'm going over my backlog of things to respond to, even though this mail was send a over a year ago this seems worthwhile to respond too.
I've currently re-opened the discussion about this here: https://gitlab.freedesktop.org/xorg/app/xinit/issues/9
Hopefully we can get some momentum on getting this fixed there.
+1. This affects xrdp sessions as well. Thanks, Hans.
Regards, Dominik
devel@lists.stg.fedoraproject.org
-
Alexey Rochev -
Dominik 'Rathann' Mierzejewski -
Hans de Goede -
stan