| Summary: | gnome-base/gnome-keyring-daemon spawns before /run/user/${user} is mounted by elogind | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pavel <nikulinpi> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gnome, kfm, nikulinpi, sven.eden |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=599470 https://bugs.gentoo.org/show_bug.cgi?id=652194 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I wonder if this is related to bug 652194 too (In reply to Mart Raudsepp from comment #1) > I wonder if this is related to bug 652194 too Those are moves in the right direction, but they wouldn't do anything with the fact that elogind mounts /run/user/${user} after gnome keyring opens a socket there Update, I just found out that removing consolekit somehow makes it so that elogind finishes mounting before gnome-keyring-daemon opens a socket in XDG_RUNTIME_DIR ConsoleKit2 and elogind can not (really) coexist peacefully. Normally nothing bad happens if you install both but only use one. Starting both could be a problem though. However, two session trackers are one too many. Nevertheless I am intrigued, as elogind should a) not mount something that is already there and b) mount it before it is needed. I am also isuing gnome-keyring, and am starting elogind via dbus call, thus without an init script. Everything works so far for me. Which version of elogind do you have installed? Well, removing CK solved my problem with gkr. I should've made a screenshot with two tmpfs mounted. One for CK and one by elogind Using elogind 235.2-r2 |
When PAM gnome-keyring module spawns gnome-keyring-daemon --login, it does so before elogind mounts /var/run/users/${user}. The gnome-keyring-daemon --login, then opens a socket on the original fs. After elogind mounts another tmpfs on /var/run/users/${user}, that socket becomes unreachable, and the gnome-keyring-daemon --start instance that will be opened later by the session manager will be unable to retrieve the password from the the first instance opened by PAM What should we do: Somehow, we need to ensure that gnome-keyring-daemon waits until elogind mounts the per-user run tmpfs before opening a socket. Please add this bug to elogind tracker #599470