| View previous topic :: View next topic |
| Author |
Message |
Jimmy2027
n00b
Joined: 12 May 2020
Posts: 30
|
 Posted: Sat Mar 09, 2024 3:18 pm Post subject: gnome-keyring-daemon[3028]: couldn't create system prompt |
 |
|
Since a recent system update my is spammed by the following error.
| Quote: | | localhost gnome-keyring-daemon[3028]: couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.keyring.SystemPrompter exited with status 1 |
Does someone know what the issue might be?
I'm launching dbus in my .xinitrc as recommended in the https://wiki.gentoo.org/wiki/D-Bus:
| Code: |
#!/bin/sh
dunst &
xcompmgr &
dwmblocks &
redshift &
exec ssh-agent dbus-launch --exit-with-session dwm > ~/.dwm.log
|
|
|
| Back to top |
|
 |
genBTC
n00b
Joined: 13 Dec 2021
Posts: 4
|
| Posted: Wed Mar 13, 2024 3:07 pm Post subject: |
|
|
Not an expert on this but
The error essentially means gnome-keyring is trying to display a GUI Prompt to ask a password to unlock itself, but its too early in the session startup process = no way to show the window was available yet, or some similar.
I dig up this thread:
https://bbs.archlinux.org/viewtopic.php?id=202754
essentially indicating a call to
dbus-update-activation-environment
should have been made somewhere, likely in the .xinitrc - or in the other pre-existing /etc/X11/xinit/xinitrc.d/ startup scripts
Maybe try adding a
| Code: | | dbus-update-activation-environment --systemd DISPLAY |
first in your .xinitrc to pass the DISPLAY variable through sooner and hopefully resolve its ability to display windows earlier.
(it will route that DISPLAY env var back through systemd so the other programs can find which DISPLAY sooner/easier - I think)
Still confusing why regular startup went wrong.
I have a feeling Dbus got auto-triggered by systemd service or elogind/PAM (ie: something else than your final .xinitrc line),
and the error is only indicating the software's inability to detect or cope with what went on. But it should.
request for other comments please |
|
| Back to top |
|
|
Jimmy2027
n00b
Joined: 12 May 2020
Posts: 30
|
| Posted: Sun Mar 17, 2024 7:37 am Post subject: |
|
|
hmm seems like I need to downgrade dbus?
I'm using openrc so | Code: | | dbus-update-activation-environment --systemd DISPLAY |
probably won't work.
Running
| Code: |
sudo ag "dbus-update-activation-environment" /etc/
|
doesn't yield anything, I have not idea what could be launching dbus.. |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 324
Location: Naarm/Melbourne, Australia
|
| Posted: Sun Mar 17, 2024 8:37 am Post subject: |
|
|
The way to use `dbus-update-activation-environment` in your particular case is to put a call to it in your dwm config file, ~/.dwm/dwmrc:
| Code: | | dbus-update-activation-environment DISPLAY # or DISPLAY=:0, probably, if for some reason dwm hasn't set it itself |
This should ensure that the value of DISPLAY is available to the D-Bus session bus that was started by `dbus-launch`. |
|
| Back to top |
|
|
Jimmy2027
n00b
Joined: 12 May 2020
Posts: 30
|
| Posted: Sun Mar 24, 2024 8:39 am Post subject: |
|
|
I tried adding | Quote: | | dbus-update-activation-environment --all |
(found it here):
| Code: |
echo "Env variable DISPLAY: $DISPLAY" > ~/.dwm_setup.log
echo "$DBUS_SESSION_BUS_ADDRESS" >> ~/.dwm_setup.log
dbus-launch >> ~/.dwm_setup.log
# see https://wiki.archlinux.org/title/GNOME/Keyring#Using_gnome-keyring-daemon_outside_desktop_environments_(KDE,_GNOME,_XFCE,_...)
dbus-update-activation-environment --all
dunst &
dwmblocks &
redshift &
exec ssh-agent dwm > ~/.dwm.log
|
still without luck. Looking at "~/dwm_setup.log" I can see that DISPLAY, DBUS_SESSION_BUS_ADDRESS, DBUS_SESSION_BUS_PID and DBUS_SESSION_BUS_WINDOWID are set.
Completely lost at this point, I guess I'll have to switch to a login manager? |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 324
Location: Naarm/Melbourne, Australia
|
| Posted: Sun Mar 24, 2024 9:27 am Post subject: |
|
|
No, that's not how to use `dbus-launch` - refer to the dbus-launch(1) man page. You need to pass `dbus-launch` a program to start. What you're doing in what you showed is starting a D-Bus session bus via `dbus-launch` and then immediately throwing away the environment it creates for its child processes, instead of starting a program in that environment. `dbus-launch` needs to be passed a specific program to launch (in this case, dwm), within whose environment all other programs will run.
i'm going to leave ssh-agent out for now, to make things simpler.
You should have an ~/.xinitrc file containing simply:
| Code: | | exec dbus-launch dwm >> ~/.dwm.log |
An `xinitrc` file is just a shell script. In the context of a shell script, `exec` roughly means "stop running this script, ignore everything else after this line, and run this program instead". What is being run is `dbus-launch`, with an argument of `dwm`. `dbus-launch` will start a new D-Bus session bus, set the DBUS_SESSION_BUS_ADDRESS variable appropriately, and then start `dwm` as a child process - and due to being a child process, the `dwm` process will inherit the environment that `dbus-launch` created, including the correct value of the DBUS_SESSION_BUS_ADDRESS variable. If it wasn't a child process, it wouldn't inherit the correct environment.
Then, in ~/.dwm/dwmrc, you set up the rest of the environment you want:
| Code: | # DISPLAY should be set at this point, but i'm not sure
# whether it will have been set at the point `dbus-launch` was
# started; you might not need this line, but it shouldn't _hurt_.
dbus-update-activation-environment --all
dunst &
dwmblocks &
redshift & |
And that's it. From the console, running
should then result in your ~/.xinitrc being run, which should result in `dbus-launch` starting `dwm`, which should then start `dunst`, `dwmblocks` and `redshift`. If all that works, open a terminal in your dwm session and run:
| Code: | | $ env | grep DBUS_SESSION |
to check that there is a value assigned to the DBUS_SESSION_BUS_ADDRESS variable. |
|
| Back to top |
|
|
Jimmy2027
n00b
Joined: 12 May 2020
Posts: 30
|
| Posted: Sun Mar 24, 2024 11:05 am Post subject: |
|
|
After trying the minimal .xinitrx | Code: | | exec dbus-launch dwm |
and still having the issue, I realized that something is actually starting the gnome-keyring-daemon on login, before the X session is started.
I guess that this is what causes the errors.
Running | Code: | | sudo ag "gnome-keyring-daemon" /etc/ |
yields this:
| Quote: | /etc/xdg/autostart/gnome-keyring-secrets.desktop:148:Exec=/usr/bin/gnome-keyring-daemon --start --components=secrets
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop:149:Exec=/usr/bin/gnome-keyring-daemon --start --components=pkcs11
/etc/xdg/autostart/gnome-keyring-ssh.desktop:148:Exec=/usr/bin/gnome-keyring-daemon --start --components=ssh
|
At login I can see two gnome-keyring-d processes running, getting their parent process with | Code: | | ps -o ppid= -p {PROCESS_ID} |
gives 1.
I guess they are being started by a init script?
At this point my main suspect is `elogind`.
I have elogind installed with "pam" and "dbus" installed with "elogind" USE flags.
Is it expected that elogind launches the gnome-keyring-daemon at login, before the X session is started? |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 324
Location: Naarm/Melbourne, Australia
|
| Posted: Sun Mar 24, 2024 11:42 am Post subject: |
|
|
| Unfortunately i don't have any experience with gnome-keyring-daemon. However, this linuxquestions.org thread suggests there might be a PAM module involved, pam_gnome_keyring.so, that's distinct from the setup (e.g. of XDG_RUNTIME_DIR) done by the elogind module. |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 324
Location: Naarm/Melbourne, Australia
|
| Posted: Sun Mar 24, 2024 11:46 am Post subject: |
|
|
| (Also, having a PPID of 1 doesn't mean necessarily something was started by init. Zombie processes can get reparented to have PPID 1.) |
|
| Back to top |
|
|
|
Desktop Environments
