FS#46366 - [systemd] DBUS_SESSION_BUS_ADDRESS not set by pam_systemd

Attached to Project: Arch Linux
Opened by Tom Yan (tom.ty89) - Monday, 21 September 2015, 07:13 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 21 September 2015, 15:00 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

After upgrading to systemd 226-1 and dbus 1.10.0-3, DBUS_SESSION_BUS_ADDRESS is not found in `printenv`, as oppose to what this news told: https://www.archlinux.org/news/d-bus-now-launches-user-buses/

[tom@localhost ~]$ printenv
XDG_VTNR=1
XDG_SESSION_ID=c1
SHELL=/bin/bash
VTE_VERSION=4002
TERM=xterm-256color
WINDOWID=20972150
USER=tom
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
MAIL=/var/spool/mail/tom
PWD=/home/tom
LANG=en_US.utf8
SHLVL=4
XDG_SEAT=seat0
HOME=/home/tom
LOGNAME=tom
WINDOWPATH=1
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=:0
XAUTHORITY=/home/tom/.Xauthority
_=/usr/bin/printenv

[tom@localhost ~]$ pgrep -a dbus
307 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
365 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
375 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
383 dbus-launch --autolaunch=4573e187ed5c4f8fb6fd42ac0b1c59b5 --binary-syntax --close-stderr

[tom@localhost ~]$ systemctl --user show-environment
DISPLAY=:0
HOME=/home/tom
LANG=en_US.utf8
LOGNAME=tom
MAIL=/var/spool/mail/tom
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
SHELL=/bin/bash
USER=tom
XAUTHORITY=/home/tom/.Xauthority
XDG_RUNTIME_DIR=/run/user/1000
This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 21 September 2015, 15:00 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See  FS#46369 
Comment by Michael (zb3) - Monday, 21 September 2015, 08:59 GMT
On my system, it is set before I start X (to .../run/user/[uid]/bus), but after running startx, it's no longer set
Comment by Bruno Santos (bms) - Monday, 21 September 2015, 09:02 GMT
Fine here.
Did you run mkinitcpio after updating systemd?
Comment by Michael (zb3) - Monday, 21 September 2015, 09:31 GMT
Are you using startx?

I've just found this line in /usr/bin/startx:

unset DBUS_SESSION_BUS_ADDRESS

Maybe this line shouldn't be present as this variable is now being set by PAM?
Comment by Bruno Santos (bms) - Monday, 21 September 2015, 09:54 GMT
Nope, I'm running a full session, but through lightdm.
Are you reffering to ~/.xinitrc? Did you try to compare with the default one? See if the line's there?

Nevertheless, it does seem rather obvious in your case...
Whether you had that line there for a reason or not I don't know.

Comment by Michael (zb3) - Monday, 21 September 2015, 10:00 GMT
You misunderstood me..

The problem is in /usr/bin/startx, so running in a full session should work
Comment by Bruno Santos (bms) - Monday, 21 September 2015, 10:19 GMT
I see, you mean the actual script..
Well, I'm not using that in this machine.
I have another machine at home without a display manager, but I'm only updating it in 2 weeks or so as I won't have it with me / have time.

In the meantime, if Tom can confirm he has the same issue, maybe this should be updated to reflect it's a problem with xorg-xinit package (if my memory doesn't fail me), rather than with systemd update.
If not, maybe you want to create a separate bug report.
Comment by Michael (zb3) - Monday, 21 September 2015, 10:34 GMT
I've already done that: https://bugs.archlinux.org/task/46369

This line is present upstream, so eventually other distros will also be affected.
Arch is fastest though :)
Comment by Bruno Santos (bms) - Monday, 21 September 2015, 10:49 GMT
Hmm... I know I told you to create a ticket, but if it's an upstream thing, it may be more worthwhile to go and preach about it directly at the source.
Arch doesn't like to maintain distro patches.
With good reason too!

Loading...