Bug 1269581 - GNOME autologin makes boot and shutdown last 90 seconds more
GNOME autologin makes boot and shutdown last 90 seconds more
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-keyring (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
AcceptedBlocker
: Reopened
: 1266650 (view as bug list)
Depends On:
Blocks: F23FinalBlocker
  Show dependency treegraph
 
Reported: 2015-10-07 11:23 EDT by Kamil Páral
Modified: 2015-11-02 12:14 EST (History)
16 users (show)

See Also:
Fixed In Version: gnome-keyring-3.18.0-4.fc23 gnome-keyring-3.18.1-2.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-19 17:07:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
journal of system booting with delay and shutting down with delay (VM) (287.65 KB, text/plain)
2015-10-07 11:25 EDT, Kamil Páral
no flags Details
list of installed packages (50.24 KB, text/plain)
2015-10-07 11:26 EDT, Kamil Páral
no flags Details
journal with gnome-keyring-3.18.0-2.fc23 (290.05 KB, text/plain)
2015-10-15 06:29 EDT, Kamil Páral
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 756059 None None None Never
GNOME Bugzilla 756708 None None None Never

  None (edit)
Description Kamil Páral 2015-10-07 11:23:14 EDT
Description of problem:
I enabled GNOME autologin in Fedora 23. The system started to take a very long time to boot and to reboot. The behavior is very similar on both VM and bare metal, but there are some fluctuations, which suggests race conditions.

Boot:
When the system seems fully booted (according to plymouth screen, the fedora logo is fully filled out) and you expect the plymouth screen to transition to gdm, the screen goes black (VM) or keeps the plymouth image frozen (bare metal) for some time. On VM, I always waited 90 seconds. On bare metal, the time varied a lot - sometimes 0 seconds, sometimes 20 seconds, sometimes 90 seconds. After that, your user session finally appears.

Shutdown:
Shutdown takes exactly 90 seconds. The screen either goes black (and on bare metal even the monitor goes into standby mode), or keeps the last image frozen and displayed (e.g. your wallpaper). According to the log, Xorg crashes. That might be a different bug from the boot issue, I don't know. After 90 seconds systemd finally kills all processes and system shuts down properly.

I attach logs from VM because that's easier for all of us to reproduce and also the boot delay is always 90 seconds for me (but again, that is likely just a race condition showing seemingly consistent behavior).

Version-Release number of selected component (if applicable):
gdm-3.18.0-1.fc23.x86_64
systemd-222-7.fc23.x86_64
xorg-x11-server-Xorg-1.18.0-0.4.20150907.fc23.x86_64
spice-vdagent-0.16.0-2.fc23.x86_64
gnome-shell-3.18.0-1.fc23.x86_64
kernel-4.2.2-300.fc23.x86_64

How reproducible:
always for me (the shut down delay 100% on both VM and bare metal, the boot delay 100% on VM and 70% on bare metal) 

Steps to Reproduce:
0. ideally have VM-on-SSD or bare-metal-with-SSD, to make the unusual delays stand out
1. enable autologin in gnome-control-center for some user
2. reboot
3. measure the time between the plymouth showing full progress and transferring into user session (on my system it usually takes just a few seconds between having the fedora logo full and seeing the login screen, and going into user session is immediate) and compare it with usual non-autologin time
4. shut down
5. measure the time it takes the machine to stop all processes and shut down

Additional info:
Please note that on VM you need to have https://bodhi.fedoraproject.org/updates/FEDORA-2015-a7f21b1850 installed to avoid bug 1269506 in order to test this.
Comment 1 Kamil Páral 2015-10-07 11:25 EDT
Created attachment 1080742 [details]
journal of system booting with delay and shutting down with delay (VM)

Somewhere around 15:28:24 is probably where plymouth transitions to black screen and I wait 90 seconds before user session appears. 15:32:16 is where X crashes and systemd starts waiting 90 seconds before shut down.
Comment 2 Kamil Páral 2015-10-07 11:26 EDT
Created attachment 1080743 [details]
list of installed packages
Comment 3 Kamil Páral 2015-10-07 11:28:58 EDT
This is coredump captured using coredumpctl, which happens during reboot:

           PID: 1180 (Xorg)
           UID: 1000 (kparal)
           GID: 1000 (kparal)
        Signal: 6 (ABRT)
     Timestamp: Wed 2015-10-07 15:32:13 CEST (34min ago)
  Command Line: /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3
    Executable: /usr/libexec/Xorg
 Control Group: /user.slice/user-1000.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-1000.slice
       Session: 1
     Owner UID: 1000 (kparal)
       Boot ID: a2d56fff400a423ca71c0d39ca105d02
    Machine ID: 5e6876234deaa74093559f88adbbd66f
      Hostname: localhost.localdomain
      Coredump: /var/lib/systemd/coredump/core.Xorg.1000.a2d56fff400a423ca71c0d39ca105d02.1180.1444224733000000.xz
       Message: Process 1180 (Xorg) of user 1000 dumped core.
                
                Stack trace of thread 1180:
                #0  0x00007f7648b4ba98 raise (libc.so.6)
                #1  0x00007f7648b4d69a abort (libc.so.6)
                #2  0x000000000059d48e OsAbort (Xorg)
                #3  0x00000000005a3e77 FatalError (Xorg)
                #4  0x000000000049d721 switch_to (Xorg)
                #5  0x000000000049e103 xf86CloseConsole (Xorg)
                #6  0x0000000000479305 ddxGiveUp (Xorg)
                #7  0x00000000005a3072 AbortServer (Xorg)
                #8  0x00000000005a3ead FatalError (Xorg)
                #9  0x000000000049d721 switch_to (Xorg)
                #10 0x000000000049e103 xf86CloseConsole (Xorg)
                #11 0x0000000000479305 ddxGiveUp (Xorg)
                #12 0x000000000043aab9 dix_main (Xorg)
                #13 0x00007f7648b37580 __libc_start_main (libc.so.6)
                #14 0x0000000000424b79 _start (Xorg)


I'll try to attach a full traceback using gdb soon.
Comment 4 Kamil Páral 2015-10-07 11:44:34 EDT
I propose this for a blocker or at least freeze exception discussion. These criteria seem to be relevant:
"Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. "
https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria#Shutdown.2C_reboot.2C_logout
Shut down "works", but takes extremely long and the PC often looks frozen (or even in a state of hardware failure, when display is off but the PC doesn't want to shut down) during that time. If at least systemd was showing "Waiting for foo service to shut down" message on the screen, it would be better, but it doesn't.

"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test. "
https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria#Default_application_functionality
Or alternatively default panel functionality, whether you want to consider gnome-control-center part of apps or system panel. It exposes autologin feature quite visibly, but it doesn't work properly (I know, it's far fetched, but I don't see any better fitting 'login' criterion.)

The problem is that autologin is quite popular functionality in home use and currently it's quite broken. Users won't tolerate waiting 90 seconds for boot and 90 seconds for shutdown.

In case the boot and shut down issues are separate (the second seems to be an Xorg crash, not sure what the first is), it might make sense to discuss them and decide on them separately.
Comment 5 Lukas Brabec 2015-10-08 04:54:07 EDT
I was able to reproduce this on bare metal with classic HDD. Startup delay seems to be quite random (from ~ 15s to 60s longer boot). Shutdown is consistent, every reboot/shutdown after auto login results in long delay and core dump (as in comment #3).
Comment 6 Kamil Páral 2015-10-08 05:45:08 EDT
(In reply to Kamil Páral from comment #3)
> I'll try to attach a full traceback using gdb soon.

The Xorg crash is now reported by abrt as bug 1269819. We can use that bug for shutdown issue tracking, if it turns out to be non-related to login issue.
Comment 7 Tim Flink 2015-10-12 12:43:21 EDT
Discussed during the 2015-10-12 blocker review meeting [1]:

Consensus was not reached WRT blocker status and the discussion will be resumed at the next blocker review meeting when more information is available.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-10-12/f23-blocker-review.2015-10-12-16.01.html
Comment 8 Tim Flink 2015-10-12 13:05:09 EDT
Discussed during the 2015-10-12 blocker review meeting [1]:

While blocker status consensus was not reached, a tested fix would be considered for inclusion in F23 final after freeze.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-10-12/f23-blocker-review.2015-10-12-16.01.html
Comment 9 Kamil Páral 2015-10-13 04:11:15 EDT
I have now verified that this affects F23 TC6 Workstation Live as well. The boot delay is again random (I have seen 60 seconds and I have seen 0 seconds), the shutdown delay is consistently 90 seconds.

We have other reports as well:
https://lists.fedoraproject.org/pipermail/test/2015-October/128110.html
(again, people consider the PC to be stuck and power it off forcefully)

This will probably make our blocker decision a bit easier :)
Comment 10 Kamil Páral 2015-10-13 07:49:16 EDT
I have narrowed this down to gnome-keyring (and most likely, gnome-keyring-pam). F23 Beta Live works perfectly, and it contains gnome-keyring-3.16.0-2.fc23. If you install it and update to gnome-keyring-3.18.0-1.fc23, the random boot delay occurs.

The shutdown xorg crash is also caused by gnome-keyring, but it only occurs with combination with other updated packages (not sure which, it's not just newer gnome-keyring + xorg, there's more to it). However, if I downgrade gnome-keyring on a fully updated F23 system, not just the boot delay, but also the shutdown delay disappears. That allows me to blame gnome-keyring for both these issues :)

I also tested gnome-keyring-3.17.91-1.fc23, it's broken as well. So the problem occurred somewhere between gnome-keyring-3.16.0-2.fc23 and gnome-keyring-3.17.91-1.fc23.
Comment 11 Ray Strode [halfline] 2015-10-13 08:03:32 EDT
duping this to bug because Owen looked into this a bit and has some deeper analysis on that bug.

*** This bug has been marked as a duplicate of bug 1266650 ***
Comment 12 Ray Strode [halfline] 2015-10-13 08:06:38 EDT
*** Bug 1266650 has been marked as a duplicate of this bug. ***
Comment 13 Ray Strode [halfline] 2015-10-13 08:10:26 EDT
making this side the master bug because it has all the blocker tracking on it.

The important bits from the other bug are these quotes from owen:

(In reply to Owen Taylor from bug 1266650 comment #1)
> I was able to reproduce this easily, and partially have this tracked own
> now. The basic problem is multiple different attempts to start the
> gnome-keyring daemon interfering with each other. When pam_gnome_keyring is
> used (for normal with-password login), gnome-keyring is started differently
> and the issue doesn't occur.
> 
> What happens, as I see it, is that there are two processes of
> gnome-keyring-daemon --secrets running. (Caveat emptor in the below... it's
> something *sort of* like this.)
> 
>  Copy A) - run by D-Bus activation from the service file, D-Bus thinks it
> has the service name, but it *doesn't*, and because of the --foreground
> option passed in the service file, it is waiting in a blocking sleep forever.
> 
>  Copy B) - run by the desktop file in /etc/xdg/autostart
> 
> For GNOME alone, what might work is to make the service files in
> /etc/xdg/autostart DBusActivatable=true so everything is launched via D-Bus
> in a race-free fashion. But the autostart files are also used by Unity and
> MATE - so perhaps what would be better is to do:
> 
>  Exec=gdbus introspect --session --dest org.freedesktop.secrets
> --object-path /org/freedesktop/secrets
> 
> Or have starting by activation be part of an executable shipped with
> gnome-keyring.

(In reply to Owen Taylor from comment #3)
> It's possible that unsplitting the autostart and starting only a single
> gnome-keyring to handle secrets/ssh/pkcs11 would hide the issue. It seems
> that is how things end up working when pam_gnome_keyring is in effect. (And
> the autostart jobs just exit immediately?)
> 
> But I do think the setup is conceptually problematical - the service file
> has:
> 
> [D-BUS Service]
> Name=org.freedesktop.secrets
> Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
> 
> But the Exec line does *not* necessarily* provide the service - it can look
> on the bus, see the name already there, and just sleep forever. I think this
> inherently runs afoul of the race-free singleton handling in the DBus server.
Comment 14 Kamil Páral 2015-10-13 09:38:20 EDT
With autologin enabled, I see these processes running:

$ pgrep -fa keyring
1149 /usr/bin/gnome-keyring-daemon --start --components=pkcs11
1151 /usr/bin/gnome-keyring-daemon --start --components=secrets
1154 /usr/bin/gnome-keyring-daemon --start --components=ssh
2129 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

> > For GNOME alone, what might work is to make the service files in
> > /etc/xdg/autostart DBusActivatable=true so everything is launched via D-Bus

I tried to add this to /etc/xdg/autostart/gnome-keyring-* but it didn't help. Maybe I was doing something wrong.

I also tried deleting all those files. That resolved boot and shutdown problems. It also reduced the number of running gnome-keyring processes to one::

$ pgrep -fa keyring
2080 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

ABRT seems to store and retrieve bugzilla credentials correctly (seahorse also displays the login keyring, after reboot, correctly).

This seems to confirm that this problem is related to what Owen described.
Comment 15 joerg.lechner 2015-10-13 10:57:21 EDT
There seem to be this problem in the F23 Final TC6 x86_64 Desktop liveCD.
I booted the liveCD, installed TC6
onto an external disk, clicked on shutdown in the menue the liveCD displays, the
screen becomes black, but the signal (a blue lamp on my Acer laptop) is still on
PC running. I had to manually unplug the PC. This is easy to verify again.
Comment 16 Kalev Lember 2015-10-14 14:08:15 EDT
Could someone try if http://koji.fedoraproject.org/koji/taskinfo?taskID=11447212 improves things, please?
Comment 17 Satish Balay 2015-10-14 21:43:03 EDT
(In reply to Kalev Lember from comment #16)
> Could someone try if
> http://koji.fedoraproject.org/koji/taskinfo?taskID=11447212 improves things,
> please?


I tried this out - but the problems persist

# rpm -q gnome-keyring gnome-keyring-pam
gnome-keyring-3.18.0-2.fc23.x86_64
gnome-keyring-pam-3.18.0-2.fc23.x86_64

- google-chrome still takes a long time to start [ as reported in #1266650 ]
- bootup and shutdown times are noticeably longer
Comment 18 core bots 2015-10-15 04:29:32 EDT
(In reply to Kalev Lember from comment #16)
> Could someone try if
> http://koji.fedoraproject.org/koji/taskinfo?taskID=11447212 improves things,
> please?

I've tried to install the package to see if the mentioned delays go away, but was kicked out of the session the second gnome-software installed it. I can't login now, on boot I end up with the console. startx gives me 'oh no!' screen. tried downgrading with no luck. does your package alter any other settings which could prevent my system from starting properly? thanks
Comment 19 Kalev Lember 2015-10-15 05:04:53 EDT
(In reply to core bots from comment #18)
> does your package alter any other settings which could prevent my system from starting properly? thanks

The only difference between 3.18.0-1 and 3.18.0-2 is that -2 has the patch from https://git.gnome.org/browse/gnome-keyring/commit/?id=3cf744f67939dc23c2cc8715cda999a7ec13f1b6
Comment 20 Kamil Páral 2015-10-15 06:29 EDT
Created attachment 1083205 [details]
journal with gnome-keyring-3.18.0-2.fc23

(In reply to Kalev Lember from comment #16)
> Could someone try if
> http://koji.fedoraproject.org/koji/taskinfo?taskID=11447212 improves things,
> please?

Doesn't seem to help. Both boot and shutdown are still delayed by 90 seconds. After boot, I see:

[kparal@localhost ~]$ pgrep -fa keyring
1446 /usr/bin/gnome-keyring-daemon --start --components=ssh
1450 /usr/bin/gnome-keyring-daemon --start --components=pkcs11
1454 /usr/bin/gnome-keyring-daemon --start --components=secrets
2139 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

Journal from boot & reboot attached.
Comment 21 core bots 2015-10-15 07:01:07 EDT
(In reply to Kalev Lember from comment #19)
> (In reply to core bots from comment #18)
> > does your package alter any other settings which could prevent my system from starting properly? thanks
> 
> The only difference between 3.18.0-1 and 3.18.0-2 is that -2 has the patch
> from
> https://git.gnome.org/browse/gnome-keyring/commit/
> ?id=3cf744f67939dc23c2cc8715cda999a7ec13f1b6

thanks, after downgrading to 3.18.0-1, running ' dnf groupinstall "Fedora Workstation" ' and disabling selinux i can boot normally again; also chrome starts promptly and there are no delays when shutting down again, surprisingly.
Comment 22 Matthias Clasen 2015-10-15 08:30:42 EDT
I think we should consider reverting to gnome-keyring 3.16 at this point.
Comment 23 Matthias Clasen 2015-10-15 08:32:20 EDT
Lets wait a few more hours before doing so... Ray wants to have a look
Comment 24 Ray Strode [halfline] 2015-10-15 09:49:26 EDT
Hi,

> > > For GNOME alone, what might work is to make the service files in
> > > /etc/xdg/autostart DBusActivatable=true so everything is launched via D-Bus
> 
> I tried to add this to /etc/xdg/autostart/gnome-keyring-* but it didn't
> help. Maybe I was doing something wrong.
So in order for DBusActivatable to work, the files have to be named using a specific convention (the name of the dbus name they'll take).  so the files have the wrong names, but only one of them gets dbus activated anyway..

> I also tried deleting all those files. That resolved boot and shutdown
> problems.
So I think this is actually right. well not all the files, but the secrets one. there's no point in autostarting the secrets service since it's used via dbus anyway. The things that should be autostarted are the agents accessed via sockets.

So the easy fix here is to not ship the gnome-keyring-secrets autostart file...
Comment 25 Ray Strode [halfline] 2015-10-15 15:06:19 EDT
okay i've pushed two changes that I think should fix this (at least for now):

1) no longer ship gnome-keyring-secrets.desktop for the reason mentioned in comment 24

2) kparal also discovered, on irc, a deadlock that causes the same symptoms but for a different reason: gnome-keyring is forking after initializing glib which is a big no no. I wrote a patch to make it fork earlier.

Unfortunately i'm the world's worst person when it comes to being able to reproduce bugs, so i'd appreciate if someone who's good at hitting bugs would try out the latest build and make sure it actually resolves the issues.

http://koji.fedoraproject.org/koji/taskinfo?taskID=11463977
Comment 26 Ray Strode [halfline] 2015-10-15 15:14:29 EDT
so playing with this in non-autologin mode i see i somehow broke the password hand off from pam
Comment 27 Ray Strode [halfline] 2015-10-15 16:10:08 EDT
so i figured out how i broke the hand off (I moved some code that closed file descriptors to an earlier place).

will do some testing and push a new fix.
Comment 28 Fedora Update System 2015-10-15 16:34:19 EDT
gnome-keyring-3.18.0-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cb9d7bac15
Comment 29 Adam Williamson 2015-10-15 16:35:36 EDT
Discussed at 2015-10-15 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-10-15/f23-blocker-review.2015-10-15-20.11.log.txt . Accepted as a blocker: the most relevant criterion - "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops" - only applies to post-install, but we agreed in principle that extending at least the 'shutdown' requirement to installer images made sense, and that will be proposed on the mailing list.

We agreed that while it's usually safe to force shutdown a live image, requiring everyone who ever boots an f23 Workstation live image to do this or wait 90 seconds is a pretty bad look and not acceptable for a final release OS.
Comment 30 Fedora Update System 2015-10-15 23:02:46 EDT
gnome-keyring-3.18.0-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update gnome-keyring'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-cb9d7bac15
Comment 31 Kamil Páral 2015-10-16 05:21:41 EDT
gnome-keyring-3.18.0-4.fc23 fixes all the issues for me. Great work, Ray. I tested both autologin and passworded-login, I spotted no issues. Seahorse worked fine, ABRT saved and loaded from keyring, and I saw no login or reboot delays (tested with many many reboots).

One thing, though. Ray, in gnome-keyring-3.18.0-3.fc23 you removed gnome-keyring-secrets.desktop file, in gnome-keyring-3.18.0-4.fc23 you added it back. Is that intentional? I tested both with and without this file and haven't spotted any issues. Still, I wonder if it's a simple mistake and the file should not be there.
Comment 32 Ray Strode [halfline] 2015-10-16 13:15:02 EDT
It's actually intentional:

* Thu Oct 15 2015 Ray Strode <rstrode@redhat.com> 3.18.0-4•
...
- Remove unneccessary part of autologin fix•

Turns, out the second file doesn't cause problems when we fix the deadlock, and I'd rather keep changes as minimal as possible at this stage to minimize risk.  Sorry for forgetting to mention that, and thanks for the keen eye/careful review. Appreciated.
Comment 33 joerg.lechner 2015-10-16 13:51:35 EDT
Just run the F23 Final Desktop TC11 Live CD on an usb flash medium.
Shutdown by power off via menue successful. PC automatical totally shut down.
Comment 34 Kalev Lember 2015-10-17 10:48:53 EDT
We have another bug report, https://bugzilla.redhat.com/show_bug.cgi?id=1272646 where people are saying that they are unable to log in to Xfce and MATE with lightdm. Stef thinks that the gnome-keyring fixes that went upstream might possibly fix this.

I'm doing a 3.18.1 build with the upstreamed fixes, let's see how it goes. Hopefully it doesn't auto-obsolete the update in bodhi so that we can choose which one to pick for the images.
Comment 35 Fedora Update System 2015-10-17 10:50:02 EDT
gnome-keyring-3.18.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b63ce6ef7b
Comment 36 Fedora Update System 2015-10-17 14:20:46 EDT
gnome-keyring-3.18.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update gnome-keyring'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b63ce6ef7b
Comment 37 Fedora Update System 2015-10-17 15:02:26 EDT
gnome-keyring-3.18.1-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b63ce6ef7b
Comment 38 Fedora Update System 2015-10-18 15:53:30 EDT
gnome-keyring-3.18.1-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update gnome-keyring'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b63ce6ef7b
Comment 39 Kamil Páral 2015-10-19 10:09:51 EDT
Seems to work well with gnome-keyring-3.18.1-2.fc23.
Comment 40 Fedora Update System 2015-10-19 17:07:33 EDT
gnome-keyring-3.18.1-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.