FS#46374 - [systemd] [dbus] Automatically activated session dbus does not inherit DISPLAY environment variable

Attached to Project: Arch Linux
Opened by Simonas (nagi) - Monday, 21 September 2015, 12:26 GMT
Last edited by Toolybird (Toolybird) - Saturday, 03 June 2023, 02:04 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Dave Reisner (falconindy)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 23
Private No

Details

Description:

Recently updated systemd/dbus will now launch session dbus-daemon. Daemon, however, is not provided the DISPLAY environment variable, breaking some programs relying on dbus activation having the variable.

Some examples are:

gnome-terminal fails with

Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 1

Additional info:
* package version(s) local/libsystemd 226-1 local/dbus 1.10.0-3 local/gnome-terminal 3.16.2-1

Steps to reproduce:

1. Use systemd capability to launch session dbus daemon;
2. Try launching gnome-terminal.
This task depends upon

Closed by  Toolybird (Toolybird)
Saturday, 03 June 2023, 02:04 GMT
Reason for closing:  Fixed
Additional comments about closing:  Old and stale. If it's still a issue, please report upstream. But it was supposedly fixed with vte 0.60
Comment by Dave Reisner (falconindy) - Monday, 21 September 2015, 13:19 GMT
> Recently updated systemd/dbus will now launch session dbus-daemon.
Actually, it launches a *user* dbus, not a session dbus. That's the key change in pkgrel=3.

How are you starting X? This sounds like it might be a duplicate of  FS#46369 
Comment by Simonas (nagi) - Monday, 21 September 2015, 14:57 GMT
I do not use startx and

$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus

is set properly, therefore this cannot be duplicate of  FS#46369 .

---

I perfectly understand how having a DISPLAY inside of user dbus-daemon makes little sense, there *is* some dbus-activatable services that rely on `DISPLAY` (and probably more) being set, which systemd won’t pass through. Namely at least gnome-terminal{,-server} and anything that depends solely on libsecret+gnome-keyring-daemon+gcr.

If I do something along the lines of `dbus-update-activation-environment --all` in my xinit file, it will import DISPLAY and at least some things will begin working again, but most notably, not the gnome-keyring-daemon.
Comment by Simonas (nagi) - Monday, 21 September 2015, 15:06 GMT
More about gnome-keyring-daemon:

Sep 21 18:00:27 kumabox gnome-keyring-daemon[7743]: couldn't create system prompt: Error spawning command line 'dbus-launch --autolaunch=8dad9ba567b4445ba3746b48b0f6ca63 --binary-syntax --close-stderr': Child process exited with code 1
Sep 21 18:00:27 kumabox gnome-keyring-daemon[7743]: ** (gnome-keyring-daemon:7743): WARNING **: couldn't create system prompt: Error spawning command line 'dbus-launch --autolaunch=8dad9ba567b4445ba3746b48b0f6ca63 --binary-syntax --close-stderr': Child process exited with code 1

is output every time something that’s not PAM tries to unlock the login keyring and gnome-keyring-daemon tries to spawn the password input dialog.
Comment by Dave Reisner (falconindy) - Monday, 21 September 2015, 16:28 GMT
> I do not use startx
Then what *do* you use?

> there *is* some dbus-activatable services that rely on `DISPLAY` (and probably more) being set, which systemd won’t pass through
But we have /etc/X11/xinit/xinitrc.d/50-systemd-user.sh which does exactly this...
Comment by Simonas (nagi) - Monday, 21 September 2015, 17:56 GMT
> Then what *do* you use?

Slim. Only now I noticed it is not maintained anymore… shame.

> But we have /etc/X11/xinit/xinitrc.d/50-systemd-user.sh which does exactly this...

Ah, my bad, didn’t source that.

---

Anyway, I’ll try a different DM and report back.
Comment by Simonas (nagi) - Monday, 21 September 2015, 19:17 GMT
lightDM didn’t fix the keyring thing either.
Comment by Börje Holmberg (linfan) - Tuesday, 22 September 2015, 11:16 GMT
I also notice that systemd 226 breaks gnome. Terminal won't start and gnome-tweak-tool settings aren't saved. I have put the update in IgnorePkg. I do use startx and there is nothing that can make me use gdm or any equivalent. So, is there a way to make systemd 226 behave as systemd 225 or is the only way never to do any pacman -Syu once you got your system as you like it to look and function? It is also very annoying that all systemd updates overwrites your manual changes, like, for instance, the getty services disabling Disallocate.

The minimum requirement with these kinds of system breaking upgrades would be to at least
1) inform that this upgrade will break your wm and
2) what additional things to do to get it to work with reference to file and things to change, not just a general vage information of something that needs to be done.
Comment by Dave Reisner (falconindy) - Tuesday, 22 September 2015, 12:17 GMT
It's 215/216, not 125/126.

> The minimum requirement with these kinds of system breaking upgrades...
We kept dbus in [testing] for over a week and had no reports of breakages. So, we moved it to [core]. If you'd like to help catch these sorts of breakages sooner, please help us out and use [testing], rather than mindlessly pontificating. The intention was not to break your WM, as the news item we posted states.
Comment by Börje Holmberg (linfan) - Tuesday, 22 September 2015, 13:38 GMT
Ok, checked with the systemd folks and they consider it being a dbus problem. When i get home i will reinstall systemd 226 and downgrade dbus and see how it goes.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 22 September 2015, 18:46 GMT
Does your user's systemd --user have trouble starting?
Comment by Simonas (nagi) - Tuesday, 22 September 2015, 18:51 GMT
> Does your user's systemd --user have trouble starting?

I don’t recall having any problems with that.

> I also notice that systemd 226 breaks gnome. Terminal won't start and gnome-tweak-tool settings aren't saved.

This issue contains at least two potential fixes to this problem:

1) Sourcing /etc/X11/xinit/xinitrc.d/50-systemd-user.sh from your xinit;
2) Calling `dbus-update-activation-environment --all` in your xinit (which is what 1) is supposed to do for you).
Comment by Börje Holmberg (linfan) - Tuesday, 22 September 2015, 21:27 GMT
no problem starting, just have to redo all tweaks on every login. What is meant by Sourcing /etc/X11/xinit/xinitrc.d/50-systemd-user.sh from your xinit? How is it done?
Comment by Börje Holmberg (linfan) - Tuesday, 22 September 2015, 22:02 GMT
ok, hope it is working now, cp over xinitrc from etc to HOME/.xinitrc and edited it and added exec gnome-session.
Comment by Börje Holmberg (linfan) - Wednesday, 23 September 2015, 09:21 GMT
Yay :-) Still working so I get it has been fixed for me.
Comment by chrys (chrys87) - Thursday, 24 September 2015, 16:08 GMT
i notice similar problems using
systemctl enable gdm

gnome cant start after that update.
Comment by Bhaskar Chowdhury (unixbhaskar) - Thursday, 24 September 2015, 17:44 GMT
yep ..tried all the tricks mentioned here ...not happening...gnome-terminal not coming up...probably need to wait for fix..

Comment by Jelle Plantenberg (yellius) - Thursday, 24 September 2015, 19:00 GMT
Seems I have the same issue with nautilus
Comment by Chris Wong (lfairy) - Friday, 25 September 2015, 05:17 GMT
> What is meant by sourcing /etc/X11/xinit/xinitrc.d/50-systemd-user.sh from your xinit? How is it done?

I added the following to my .xinitrc:

includes=/etc/X11/xinit/xinitrc.d
if [ -d "$includes" ]
then
for f in "$includes/"*
do
[ -x "$f" ] && . "$f"
done
unset f
fi
unset includes

See https://wiki.archlinux.org/index.php/Xinitrc#Configuration
Comment by Grollicus (Grollicus) - Friday, 25 September 2015, 14:30 GMT
This is also broken in xfce4 - org.freedesktop.Notifications is missing $DISPLAY.

My bandaid fix was to source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh in /etc/xdg/xfce4/xinitrc.
Comment by Benjamin Hodgetts (Enverex) - Friday, 25 September 2015, 16:11 GMT
The bandaid works but is there a "proper" way to fix this? I'd like to avoid a random bandaid due to the fact that it may conflict with the real fix later by which point I will have forgotten about the hack to make it work in the meantime.

This does indeed break notify-send in XFCE4 which is causing some real confusion.

This isn't working for me, trying to run "dbus-update-activation-environment --all" as the user gives me "Failed to connect to socket" as if DBus isn't running (or the user doesn't have access to it).
Comment by abaya (yakoub) - Monday, 28 September 2015, 05:13 GMT
i had same problem and i use startx method .
i couldn't start gnome-terminal or nautilus .

my mistake was after copying /etc/X11/xinit/xinitrc to .xinitrc was to delete all lines after the comment "start some nice programs" and replacing it with exec gnome-session .
but the first block of those commands was indeed responsible for including scripts under xinitrc.d .

now i can start all gnome programs noramlly .
Comment by Michael Dressel (mdrslmr) - Thursday, 01 October 2015, 09:25 GMT
I'm using gdm on a system acquiring my home directory via afs. The dbus/libdubus upgrade causes the afs token to be lost some time during the login procedure. The token is acquired by aklog. And that seams to work during the PAM login, but once I'm logged in the token is gone.
When I do acquire the token manually by aklog and than log out and back in again it is still available.
I downgraded dbus/libdbus and can confirm that the problem is not present with the 1.10.0-2 version.
Comment by Jan Alexander Steffens (heftig) - Thursday, 01 October 2015, 10:12 GMT
Where is afs in the PAM stack? Where is the token stored?
Comment by Michael Dressel (mdrslmr) - Thursday, 01 October 2015, 12:07 GMT
I don't know where the token is stored. But it looks like it depends on if the token is obtained via gdm via PAM or if I do it manually.

I'm using pam_krb5.so and pam_afs_session.so in the auth and session part of the PAM.
Comment by Jan (dl1jph) - Friday, 02 October 2015, 07:48 GMT
One extremely ugly workaround that got at least most of my Desktop environment back running (pulseaudio is not cooperating quite yet) was to dbus-launch my desktop session (i3).

For what ever that means, I'm properly sourcing the xinitrc.d-scripts during startup (including 50-systemd-user.sh), but manually running dbus-update-activation-environment --all just tells me "Failed to connect to Socket" without the workaround above. Truth is, I'm pretty much out of ideas as to what might be going on and I'm not even entirely sure if we're all seeing the same bug here, as some people seem to be doing just fine with xinitrc.d 50-systemd-user.sh while it doesn't seem to do anything for others.
Comment by Jeremy M. (jskier) - Friday, 02 October 2015, 15:09 GMT
Does anyone know how to make the workaround persistent with gdm? It doesn't seem to parse /etc/X11/xinit/xinitrc.d/ or the user .xinitrc, I have to manually run dbus-update-activation-environment --all each boot.
Comment by Matthias Lisin (matthias.lisin) - Sunday, 04 October 2015, 13:07 GMT
for a quick workaround, use a drop-in config with a fixed DISPLAY var.

My Example:

# /etc/systemd/system/user@.service.d/display.conf:
[Service]
Environment=DISPLAY=:0


See also: https://wiki.archlinux.org/index.php/Systemd/User#Environment_variables
Comment by Adrián Etchevarne (saknussemm) - Tuesday, 06 October 2015, 20:05 GMT
I think that the AFS ticket is stored in the session keyring (you can see it in 'keyctl show'). If $HOME is in afs, now dbus (and child process) can't access any user file (for example, firefox always fail to set the default browser).

I suspect that in some encrypted setups, systemd-user-dbus will fail similary.
Comment by Mirandir (mirandir) - Wednesday, 07 October 2015, 15:50 GMT
This problem seems to affect some XDG environment variables, too. For example with GDM and Gnome, 'XDG_CURRENT_DESKTOP' had the value 'GNOME' before the upgrade, his value is empty after. Running dbus-update-activation-environment --all 'solves' the problem.
Comment by Alex Seiler (aexl) - Wednesday, 07 October 2015, 22:26 GMT
Does anybody know, if this problem got fixed in systemd-227?
Comment by Michael Dressel (mdrslmr) - Thursday, 08 October 2015, 14:20 GMT
Yes, "keyctl show" displays the afs_pag as being in "keyring: _ses.846".
This result I obtained when using the previous dbus version.
Comment by Jan Alexander Steffens (heftig) - Thursday, 08 October 2015, 14:22 GMT
Can you get AFS to store the keys in the user keyring instead? Since systemd --user is started from outside the session, it does not have access to the same session keyring.
Comment by Michael Dressel (mdrslmr) - Thursday, 08 October 2015, 14:54 GMT
@heftig I don't see an obvious way how to do that. The pam modules I checked didn't provide such option.

@saknussemm My home directory is mounted via AFS. Are the keys tried to be stored on my home directory? where?
Comment by Adrián Etchevarne (saknussemm) - Thursday, 08 October 2015, 22:04 GMT
I cannot see an option to store the AFS token in the user keyring, neither in pam_afs_sesssion or aklog. I am reading about keyctl, maybe the keys can be moved/linked?

@mdrslmr the AFS token is stored in memory, in the keyring. BUT: the kerberos ticket is stored in the filesystem, in /tmp/krb5cc_$UID_xxxx by default; with that you can call aklog.

A workaround/hack that I am testing for the AFS issue:

/etc/systemd/system/user@.service.d/override.conf:
----8<-------------
[Service]
ExecStart=
ExecStart=-/usr/bin/bash -c "export KRB5CCNAME=FILE:/tmp/krb5cc_$(id -u %i); aklog -d; exec /usr/lib/systemd/systemd --user"
----8<-------------

You must force the kerberos ticket filename in /etc/krb5.conf:
----8<-------------
[appdefaults]
pam = {
ccname_template=FILE:/tmp/krb5cc_%U
}
----8<-------------


Is there a generic way to give dbus all the environment/keys/etc. that pam* sets for the user process?

Comment by Jan Alexander Steffens (heftig) - Thursday, 08 October 2015, 22:45 GMT
You can push environment using `dbus-update-activation-environment --systemd --all`.

I just stumbled upon `man user-session-keyring`, which explains that if a process tries to access its session keyring without that keyring existing, then the kernel will assign the "user-default session keyring" to that process, which is shared by all processes of that user. If you use GDM to log in, try removing all the pam_keyinit lines from the /etc/pam.d/gdm* files. If that works, I'll implement it in the gdm package.
Comment by Michael Dressel (mdrslmr) - Friday, 09 October 2015, 10:14 GMT
f the AFS token is stored in memory and the kerberos ticket is stored in /tmp (/tmp is not mounted via AFS of course) I didn't understand what the $HOME directory is needed for in obtaining tokens or keys?

Is the user@.service.d/override.conf shown above complete?

Where would the `dbus-update-activation-environment --systemd --all` line have to go?

I tried commenting out all pam_keyinit lines in /etc/pam.d/gdm* and /etc/pam.d/system-auth. But without success.
Comment by Michael Dressel (mdrslmr) - Monday, 12 October 2015, 15:28 GMT
I also tried using override.conf as suggested above. It didn't work for me. In the logging I found:

"bash[856]: aklog: Couldn't determine realm of user:aklog: unknown RPC error (-1765328189) while getting realm"
Comment by Adrián Etchevarne (saknussemm) - Tuesday, 13 October 2015, 19:16 GMT
Make sure that you got the environment variables right. You can see them by replacing aklog by " env; aklog" . Also, make sure to use double quote (") and not single quote (') in the bash command.
Comment by Michael Dressel (mdrslmr) - Wednesday, 14 October 2015, 08:07 GMT
Thanks for the hint.
Now I use "ccache=FILE:/tmp/krb5cc_%u" in "/etc/krb5.conf"
and "KRB5CCNAME=FILE:/tmp/krb5cc_%u" in "override.conf".

It worked some times and others I think it didn't. In the case it didn't work the system unit using the override.conf was run by user gdm/120 instead of me. There may be a timing/ordering issue?
Comment by Federico (fedev) - Sunday, 25 October 2015, 03:39 GMT
Any ideas if a fix for this is being worked on?

Thanks!
Comment by Michael Dressel (mdrslmr) - Tuesday, 27 October 2015, 07:41 GMT
I don't know.

For me the workaround suggested by saknussemm works. Since my comment from 14'th October it always worked.
There still seams to be a difference between logging in right after reboot and logging in again after
logging out without reboot. In the first case some application (?) asks for the password for a keyring
in the later case it does not ask again.
Comment by Anatolii Sakhnik (sakhnik) - Friday, 18 December 2015, 16:24 GMT Comment by Bhaskar Chowdhury (unixbhaskar) - Tuesday, 26 January 2016, 12:19 GMT
So ,I ditched Gnome and install kde , that solve the problem. Is it something to do with the glue of Gnome with systemd? Now I am able to open konsole and Dolphin on Xwindow session(Kde).

I had have tried few trick from here ...not satisfied with it...heck..
Comment by Bhaskar Chowdhury (unixbhaskar) - Monday, 05 September 2016, 13:03 GMT
Well ,I tried it today and voila! it works!! the gnome-terminal is now coming up. Thanks.
Comment by Dave Reisner (falconindy) - Saturday, 05 January 2019, 16:45 GMT
Is this still relevant with more recent systemd?
Comment by kbt (kbt) - Tuesday, 12 March 2019, 18:20 GMT
Yes. I still have this bug right now.

Loading...