You are not logged in.
I'm using lightdm (configured for auto-login) to start Awesome as window manager.
When my owncloud-client started asking me for the password on every boot, I started investigating why this happens.
Trying to view my keyrings with seahorse I get the following error message:
** (seahorse:29395): WARNING **: gkr-backend.vala:85: couldn't connect to secret service: Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reachedSo I checked the dbus-related environment and I think I found the problem: issuing `env` in a terminal under Xorg I get this:
[alex@thor ~]$ env | grep -i dbus
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-2YRIFEYY2I,guid=2256bb2309b40832a0501ed2538ae018But ~/.dbus/session-bus/28b4e8e16867ef5e2f2ced63000003c2-0 contains this:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-QAQJokcmuW,guid=5316e362cfb4c45ff2f1a917538ae018When I source this file in my terminal (and export the variable) seahorse and owncloud-client are working fine again, so I suspect this must be the correct one.
So why is DBUS_SESSION_BUS_ADDRESS set to a wrong value and how can I fix that? ![]()
Last edited by lynix (2014-06-01 08:54:30)
Offline
Did some further investigation and found out the following:
There were two dbus session bus instances started: one by lightdm and another one by the script /etc/X11/xinit/xinitrc.d/30-dbus.
Some way the window manager inherited the first one, while the applications started afterwards got the second one, which overwrote the environment in ~/.dbus/session-bus.
My current solution (or maybe just workaround?) is to remove /etc/X11/xinit/xinitrc.d/30-dbus (or just comment all lines).
This way I only have one bus instance with valid environment in ~/.dbus/session-bus and everything is fine ![]()
If I were to guess, then I'd say the xinitrc-script does not recognize the already running dbus instance because dbus does not export DBUS_SESSION_BUS_ADDRESS anymore, and therefore starts a second one. Maybe I should file a bug report on this?... Anyway, this will hopefully get solved when kdbus has come.
Offline
There were two dbus session bus instances started: one by lightdm and another one by the script /etc/X11/xinit/xinitrc.d/30-dbus.
The script 30-dbus doesn't run by itself, so you'd rather find why it is run and by which program and prevent this from happening if it is not wanted.
My current solution (or maybe just workaround?) is to remove /etc/X11/xinit/xinitrc.d/30-dbus (or just comment all lines).
This is not a good solution to change a file which is part of a package installed by pacman.
If I were to guess, then I'd say the xinitrc-script does not recognize the already running dbus instance because dbus does not export DBUS_SESSION_BUS_ADDRESS anymore, and therefore starts a second one. Maybe I should file a bug report on this?...
I don't use lightdm: does it really use xinitrc?
And dbus doesn't export anything, it is a script which does this; so I think the problem is not with the 30-dbus script, but with lightdm which apparently doesn't export DBUS_SESSION_BUS_ADDRESS when creating the dbus instance.
But I think a better way to work around this, would be to add an 'export DBUS_SESSION_BUS_ADDRESS' somewhere after the first creation of it by lightdm, and/or to prevent the 30-dbus script from being run if this is not necessary.
Offline
The script 30-dbus doesn't run by itself, so you'd rather find why it is run and by which program and prevent this from happening if it is not wanted.
I think it is run by lightdm, cause I only start lightdm via systemd and nothing else.
This is not a good solution to change a file which is part of a package installed by pacman.
I know, this is why I wrote "maybe just a workaround"
So I'm trying to solve this the clean way now:
I removed all changes done to packaged files (30-dbus) and disabled any startup applications I had in my awesome-config. Booting my machine I first get a messed up DBUS-environment again.
But here comes the strange part: when I log off now, and log directly back in, the DBUS environment is fine again!
How can this be?
Maybe it's got something to do with lightdm autologin, I'll start looking in that direction...
Offline
The script 30-dbus doesn't run by itself, so you'd rather find why it is run and by which program and prevent this from happening if it is not wanted.
Found proof for lightdm starting the script in question:
/etc/lightdm/Xsession (included in ligthdm package):
(...)
# Run all system xinitrc shell scripts.
xinitdir="/etc/X11/xinit/xinitrc.d"
if [ -d "$xinitdir" ]; then
for script in $xinitdir/*; do
echo "Loading xinit script $script"
if [ -x "$script" -a ! -d "$script" ]; then
. "$script"
fi
done
fi
(...)So maybe a cleaner solution would be to add a new script in /etc/X11/xinitrc.d that is run before 30-dbus and fixes the environment using the value from ~/.dbus/session-bus...
Offline
The file '/etc/lightdm/Xsession' is in the backup list of the lighdm package PKGBUILD.
So you can change this Xsession file to prevent it from running the '/etc/X11/xinit/xinitrc.d/30-dbus' script, if this is the problem.
Your changes will be preserved by pacman when the lightdm package is updated.
So this is a better choice to change something than the 30-dbus script which is not included in a backup list.
Offline
Thanks for the hint, didn't notice the file is in backup[].
My current solution is another script, /etc/X11/xinit/xinitrc.d/31-fix-dbus which reads the correct DBUS_SESSION_BUS_ADDRESS from ~/.dbus/session-bus/ and exports it.
But I suspect there must be something terribly wrong, as I still see two dbus-sessions running under my UID. I haven't the slightest idea what, apart from the script in xinitrc.d, starts the second dbus instance...
I'd love to get back to my old setup, without any login manager, but I need my gnome-keyring unlocked automatically, and I think using a login manager that does the unlock via PAM is the easiest way.
Offline
Please post your '/etc/X11/xinit/xinitrc.d/31-fix-dbus' script.
And the 31-fix-dbus script will be run after the 30-dbus script, is it not too late to export a DBUS_SESSION_BUS_ADDRESS variable then?
Alternatively you can change the lightdm Xsession file like that:
# Run all system xinitrc shell scripts.
xinitdir="/etc/X11/xinit/xinitrc.d"
if [ -d "$xinitdir" ]; then
for script in $xinitdir/*; do
echo "Loading xinit script $script"
if [ -x "$script" -a ! -d "$script" -a "$script" != "/etc/X11/xinit/xinitrc.d/30-dbus" ]; then
. "$script"
fi
done
fiAnd delete your 31-fix-dbus script.
Take note also that lightdm uses a system dbus instance, and the 30-dbus script creates a session dbus instance; that may be the source of the confusion.
Last edited by berbae (2014-06-19 09:53:52)
Offline