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
Opened by Simonas (nagi) - Monday, 21 September 2015, 12:26 GMT
Last edited by Toolybird (Toolybird) - Saturday, 03 June 2023, 02:04 GMT
|
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
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
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$ 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.
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.
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...
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.
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.
> 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.
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).
systemctl enable gdm
gnome cant start after that update.
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
My bandaid fix was to source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh in /etc/xdg/xfce4/xinitrc.
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).
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 .
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.
I'm using pam_krb5.so and pam_afs_session.so in the auth and session part of the PAM.
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.
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
I suspect that in some encrypted setups, systemd-user-dbus will fail similary.
This result I obtained when using the previous dbus version.
@saknussemm My home directory is mounted via AFS. Are the keys tried to be stored on my home directory? where?
@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?
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.
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.
"bash[856]: aklog: Couldn't determine realm of user:aklog: unknown RPC error (-1765328189) while getting realm"
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?
Thanks!
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.
I had have tried few trick from here ...not satisfied with it...heck..