Bug 92064 - Unseting session environment variables breaks user dbus instances
Summary: Unseting session environment variables breaks user dbus instances
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xinit (show other bugs)
Version: git
Hardware: Other Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-21 11:20 UTC by sgv
Modified: 2018-08-10 20:30 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description sgv 2015-09-21 11:20:31 UTC
This line in startx script:

unset DBUS_SESSION_BUS_ADDRESS

which was introduced in commit c07501f69239e9c1448736ad7e689a2c3da49af9, breaks the new behaviour of pam_systemd which sets this environment variable to point to the user bus, so that applications relying on session bus do not need to spawn another instance and dbus-launch is no longer necessary.

With this line, those applications won't work properly.
Comment 1 Pekka Paalanen 2016-11-02 10:40:59 UTC
I allowed systemd to start the user session bus automatically, and found this very issue.

The file /etc/X11/xinit/xinitrc.d/80-dbus expects DBUS_SESSION_BUS_ADDRESS to be set if the session bus is already started, otherwise it starts one. This file is a Gentoo addition with reference to https://bugs.gentoo.org/show_bug.cgi?id=77504 (solved before the mentioned xinit commit): https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/dbus/dbus-1.10.12.ebuild#n205

Is using 'startx' completely frowned upon by upstream and it's a distribution responsibility to support it now?

How much there is left of the motivation for c07501f69239e9c1448736ad7e689a2c3da49af9? I did not quite understand why it was done; you always run 'startx' from within a session and do not want it to create a new session (it cannot, even). I've been asking about not being able to run several independent sessions as the same user, to which I have been educated as "no, you cannot do that anyway".

Should that commit be reverted as a whole, or should SESSION_MANAGER still be cleared?

What's the upstream opinion on this issue?
Comment 2 Adam Jackson 2016-11-02 13:26:21 UTC
(In reply to Pekka Paalanen from comment #1)

> How much there is left of the motivation for
> c07501f69239e9c1448736ad7e689a2c3da49af9?

How much do I remember about a change I wrote eight years ago? Very little, I'm afraid. I assume I did it because it was necessary then. If it isn't anymore, great, take it out.
Comment 3 Pekka Paalanen 2016-11-03 13:42:13 UTC
(In reply to Adam Jackson from comment #2)
> (In reply to Pekka Paalanen from comment #1)
> 
> > How much there is left of the motivation for
> > c07501f69239e9c1448736ad7e689a2c3da49af9?
> 
> How much do I remember about a change I wrote eight years ago? Very little,
> I'm afraid. I assume I did it because it was necessary then. If it isn't
> anymore, great, take it out.

I do not understand why it would have ever been a good thing, so I cannot understand if it's safe to remove or not. It seems to hinder one thing, but I have no idea what removing it might break. Hence I'm hesitant to propose a patch to just remove it, especially as I'm not familiar with the session stuff.

Ajax, can you remember if you were perhaps running startx from an X11 terminal to start a second "X session" in the past? Would that even be (have been) a valid use case? Or maybe some other use case?
Comment 4 GitLab Migration User 2018-08-10 20:30:51 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/app/xinit/issues/9.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.