After you reach the state as described above and in the included screenshot, could you please open a new tab and type about:sync. Then copy paste the sync stats here to help us diagnose.

Also, do you still experience the same if you disable Passwords? After you started Chrome were you ever prompted to provide the gnome keyring?

* about:sync dump is attached.
* I selected "Never save passwords" radio button before trying to set up sync, but during sync it was restored to "Offer to save passwords" (seems that this setting was synced from my account).
* No, I wasn't prompted to provide the gnome keyring.

chromium-sync-dump.txt 15.1 KB View Download

Yes, this is a preference that gets synced.

I meant actually to 'Customize' sync as you start signing in, select from the drop-down to be able to choose which data types are to be synced. Then uncheck 'Passwords' as a syncing data type. Then continue with sync.

Mike, are you aware of situations where the gnome keyring might remain locked? Thus sync when passwords sync is enabled will be stuck as it does not have access to the password store. 

I'm not aware of a way for that to happen, no. For most people the keyring unlocks on login and is always accessible after that, so the prompt would never even appear. If the prompt were displayed but somehow hidden behind the browser window or something, then maybe something like this could possibly happen? But that seems unlikely.

I tried your workaround with disabling 'Passwords' sync, and it successfully worked. Thank you very much!

By the way, I tried to find Gnome keyring dialog window under Chromium, but it wasn't there.

For me, this problem happens on two different Ubuntu machines (one of them is fresh installed), so I think it won't be difficult for you to reproduce this.

I'll try to reproduce this.

I can't seem to get this to happen with Chrome 16.0.891.0 on Ubuntu 10.04. Do you have any passwords saved? Are there any passwords listed in the "Passwords and Encryption Keys" application in the Accessories folder in the Applications menu?

Actually I am seeing a repro (clean local profile, first time sync) and am indeed not prompted to unlock the keyring.

Let me repeat: you are normally *not supposed* to see a prompt to unlock the keyring. That is an unusual circumstance that we have created for ourselves inside Google, especially on machines not used daily, where the keyring can get locked automatically.

But since you can reproduce it, I have the same question for you - what's in your passwords and encryption keys app? Is your keyring daemon running (ps auxw | grep gnome-keyring-daemon)? Does the issue happen if you view the passwords once before attempting to set up sync? Does it still happen if you log out and back in? How about if you reboot? (I know you'll be worried that the issue will go away, but knowing whether the cause is in transient or persistent state could be important.)

Don't believe it was suggested that keyring prompt is expected at *all* interactions with the password store. Either way, the current behavior is certainly a regression in the way the gnome keyring interacts with password sync. Running the browser with --password-store=basic actually does not exhibit the issues in this bug. Password sync in particular is successful. Whether it is the password store that is misbehaving or whether it is locked and cannot be unlocked when needed from within Chrome it is up to investigation. The passwords and encryption keys app shows some passwords, however any attempt to list them actually freezes it. The daemon is running.  Updating title accordingly.

An additional point: sign in sync with password sync disabled, enable (and hence run into the infinite spin), restart the browser. Profile corruption error is shown as well as:
[26868:26883:609124207290:ERROR:web_data_service.cc(617)] Cannot initialize the web database: 1
[26868:26868:609124270378:ERROR:CONSOLE(1)] "Uncaught ReferenceError: updateLogin is not defined", source:  (1)
[26868:26868:609124270459:ERROR:CONSOLE(1)] "Uncaught ReferenceError: new_tab is not defined", source:  (1)
[26868:26868:609134813963:ERROR:profile_impl.cc(1210)] Could not initialize login database.

I see a prompt to unlock the keyring every chrome start. After that, I can't browse some webs like gmail and google reader.

I'm experiencing this issue with two instances of Debian GNU/Linux 6.0.2 (squeeze) machines (32, 64). It happens on all current linux Chrome versions. 

Chrome works properly after killing gnome-keyring-daemon

Are you, in fact, unlocking the keyring? Or are you just leaving the prompt there? Or hitting cancel? Are you using sync?

Yes, I unlock the keyring and I'm using sync apparently without other problems

I experienced this first time with chrome 14 beta. 

First I thought it was a cache problem because when I tried to use some google services (like gmail, reader or calendar, but for instance google maps always works perfectly) there was a "waiting for cache" message on the status bar.

I seem to have turned this into a 100% repro with the attached patch (something I added to help test an unrelated feature), and just trying to sign in to sync.  

I actually made this change ~1 week ago and it was working fine, but I only got back to playing with this branch today, and now it hangs :/

pss.diff 714 bytes View Download

hit send too soon

We seem to be stuck waiting on line 384 of native_backend_gnome_x.cc, but sync is trying to shutdown (due to the UnrecoverableError I triggered in my patch)

Tim, is the UI thread stuck waiting on something as well? Is sync on the UI thread? Or is the UI thread just trying to acquire one of sync's locks?

I also get gnome-keyring password prompt on Fedora 14 every time I start Chrome. I press "Cancel" and everything seems to work normal, I login to gmail, etc..

BTW, I had followed instructions to delete and create a new keyring with a password matching the login password but that didn't help.

I'm going to try looking into this, though I don't know much about password storage.  If someone who is familiar with password storage wants this bug they can have it.  

I had some trouble reproducing this because I'm not using Gnome as my DE.  Let this be a lesson to others: it's a good idea to explicitly specify --password-store=gnome.

I've spent a bit of time examining the state of the system after using Tim's patch to reproduce this.  I suspect this freeze is not quite the same as the one that was originally reported.  The freeze I see is on the UI thread; Chrome stops redrawing itself.  Comment #2 implies that the UI was still responsive for the user, so that hang must have been on a different thread.  

That being said, here's what the system looks like after the freeze:
UI thread:
* The UI thread is blocked during ProfileSyncService shutdown.
* The ProfileSyncService is shutting down DataTypeManagers one by one.
* The DataTypeManager currently being deleted is the PasswordDatatypeController.  It posts a PasswordDatatypeController::StopAssociation method to the DB thread, then blocks the UI thread waiting for it to finish.

DB thread:
* A PasswordManagerHandler, which I believe is used as a backend for the preferences UI, has posted a request via PasswordManagerHandler::PasswordListPopulater::Populate() in order to GetAutofillableLogins().
* This request is handled on the DB thread as PasswordStoreX::GetAutofillableLoginsImpl().
* The PasswordStoreX defers to the Gnome Keyring-specific backend, which posts a task to the UI loop and waits for it to finish.
* The PasswordDatatypeController::StopAssociation task that the UI thread is currently blocked on sits further down on this thread's pending tasks queue.

It should be noted PasswordManagerHandler::PasswordListPopulator, which was set to consumer the result of this request, appears to have been deleted.  I suspect that if CancelableRequest was able to interrupt the PasswordStore's waiting, then we might have avoided this deadlock.  I'm not sure yet if that would fix the root cause of the problem, but it's something to consider.  

I'll let those who are more familiar with the design discuss other possible solutions.  For now, I'm going to see if I can reproduce a freeze without Tim's patch.  Hopefully we can find a solution that fixes both issues, but we need to understand them both first.  

I can reproduce only part of the user's issue.  

For me, the gnome keyring dialog box will pop up if I'm not already authenticated.  If I enter my password, the sync setup completes successfully.  

If I ignore the gnome keyring prompt, then the spinner just sits there, while other tabs show my newly synced settings.  If I click cancel, the UI freezes completely.  The freeze is similar to the one triggered by Tim's patch.  This makes sense because the patch to trigger an unrecoverable error during sync setup would have similar effects to pressing the cancel button during sync setup.  

In summary, the behaviour I see when I pretend that the gnome keyring dialog box is not displayed seems to be the same as what the user sees when that dialog box is actually not displayed.  Until I fully reproduce the "infinite spin" effect for myself, I'm going to assume that it is caused by the dialog box failing to appear.

Also, I have a warning for anyone trying to reproduce this on trunk.  An unrelated change hides the spinner from the UI during sync setup, so there is no longer any cancel button to click.  You'll have to use an older revision or Tim's patch to reproduce the UI freeze.  

I don't know why the dialog box is failing to display.  It might be an OS bug.  Since a few people have reproduced it on clean Ubuntu installs, testing a fresh install seems like the logical next step in this investigation.  

Thanks for looking into this!

At the root of this problem are two causes:

1. The GNOME Keyring libraries must be used on the UI thread, but the password store is set up to run on the DB thread (also by necessity). Thus we end up having to wait for the UI thread from the DB thread.
2. The password sync code does not use the normal asynchronous password store API, and calls private synchronous methods instead. It must therefore never hold a lock, or wait on the UI thread, when doing so.

We ran into some similar problems before, as both of these features (the GNOME Keyring integration and password sync) were developed in parallel and then enabled at about the same time. At the time we were able to solve the problem by carefully avoiding holding sync locks when accessing the password store; it seems like we may now have a new bit of code that's doing something similar.

Or rather, clicking cancel to sync tells it to shut down, but it was still trying to start up in the first place. That's probably where we get into this problem where each thread is waiting for the other. The question is why the sync setup was waiting. I haven't been able to reproduce that part - I'm glad you have found some luck there! Let me know if I can help with any questions you have.

I'm still curious what would have changed in passwords code that caused this new request to occur seemingly whenever you start sync setup, since it wasn't reproing the week before last when I initially wrote that patch :/

I'm extra confused if you still haven't managed a repro if you patch that CL in...  It'd be useful for you to look, since we have a very foggy view on how this code interacts with passwords.

Sync setup / teardown hasn't changed for passwords, which is still on the old api.   It has always waited for data types to stop at shutdown.

I think an update is in order.

There are two issues here.  The first is that we sometimes see an infinite spinner during initial sync setup.  I have not been able to reproduce this, but annapop says this is easily reproducible.  I was chatting with mdm offline and he suggested this could be caused by duplicate entries in the password database.  The database is not stored in the Chrome user data directory, so it could cause problems even after the user data directory has been cleared.  Confirming this is still a work in progress.  

In the comment above, Tim is referring to the second issue.  When we try to cancel (or trigger an unrecoverable error) during the initial sync, the UI deadlocks.  I have been able to deadlock the UI thread on an older version of Chrome (M15) by cancelling the sign-in process, so I believe this is not a new issue.  It could be dependent on a race, though.  Maybe Tim was lucky enough to avoid the race when he wrote that patch last week?  

Further updates:

We have confirmed that the infinite spin issue is related to Gnome Keyring state.  After clearing annapop's list of keys, the issue is no longer reproducible.  I'm not sure yet if it's a logical inconsistency in the keyring or its enormous size that is causing the problem.  We have produced a "pruned" keyring that should help narrow down whether this is a logic error or a performance problem.  

The pruned keyring does not trigger the issue on my desktop  This is evidence against the "corrupt database" theory, though it doesn't disprove it.  It's possible (though unlikely) that the corrupt entries were removed when we tried to prune the keyring.  

The next best hypothesis I can think of is that it's the size of the keyring that's causing problems.  There may be a bottleneck somewhere in the Chrome code that chokes when the user's keyring contains 5000+ entries.  

To whoever is experiencing this issue, can you please verify what is the order of keys in your gnome keyring (check Passwords and Encryption Keys)? 

I am experiencing this issue and my gnome keyring is empty. This is because I have never used it.

Thanks, gotru.  We really appreciate your quick response.  

Unfortunately, I have to follow up with a dumb question: Are you sure you've unlocked the keyring?  

The passwords and encryption keys app displays locked keyrings as empty.  If you right click on the "Passwords: default" entry in the "Passwords" tab you might see the option to unlock the keyring.  This is easy to miss, so I figured I should double-check to make sure you've gotten it right.  

https://docs.google.com/leaf?id=0B3UfZKAvHwd9ZjEyNmU5ZTktZTRjNS00ZDI2LWE3ZTYtNGVhMWQxZTcwODQ2&hl=en_US

Thanks for the update! 

We've found evidence that the gnome keyring state can cause problems in the password manager UI before sync is enabled, so it's likely that the infinite spin in sync is just exposing an underlying issue in the password database.  At least that's what's happening in the one repro case we do have.  gotru's case is still a mystery to me.  

Let's use this issue to track the infinite spin / no passwords in the UI issue.  I've created  issue 100074  to track the deadlock.  

mdm will continue this investigation because he is more familiar with gnome keyring.  

 Issue 99922  has been merged into this issue.

OK, so with the help of Anna's keyring, I have discovered that it's very slow to write to very large (thousands of entries, MiB of size on disk) keyrings. (Reading is generally still fast, at least for the reads we do that only return a few results.)

Attempting to set up sync with such a keyring will involve numerous requests to the GNOME Keyring daemon that will cause it to use lots of CPU time, and while it's doing that, the DB thread will be blocked. Also, during this time the UI thread must not block on the DB thread or a deadlock will result, because the DB thread needs to post tasks to the UI thread to access GNOME Keyring.

I can't actually get the UI to sit there spinning, as reported, but it is in fact working in the background for quite some time. An attempt to stop sync will result in a deadlock, which is expected given the above.

I think the safest way out of this in the short term is to pull GNOME Keyring access out of process, so that we no longer need to involve the UI thread in accessing it. That will avoid the deadlock, though large keyrings will still take a long time to write to. (I suspect Anna's may, however, be among the largest keyrings ever created.) I will try to do this as soon as possible.

In the long term, the sync code should not count on a blocking API to access passwords. Removing this requirement would allow us to refactor the password store code to not block the DB thread on such slow keyring operations either.

All of this analysis does nothing to explain gotrunks' issue. It may be unrelated but just have the same symptoms.

Awesome investigation, guys!

And I feel wickedly proud about my keyring. Testing FTW. :)

I now have a small proxy binary that can do all the same GNOME Keyring accesses as the password store currently does. Working on connecting it up.

 Issue 101160  has been merged into this issue.

I was experiencing the same issue in Chrome v15.0.874.106 stable on Linux when attempting to "Sync Everything". Disabling the password sync option under customized sync worked for me too, but that's still a bug present in the latest stable release.

 Issue 102870  has been merged into this issue.

run into this issue on both a 32-bit non-corp Gubuntu and 64-bit corp account Gubuntu with Chrome 17.0.928.0

Just a quick thought on this, seems like comment #35 made by mdm is actually the best solution to the problem. Yesterday, out of the sudden, launching stable Chrome 15.0.874.106 in my Fedora 16 caused gnome-keyring-daemon to go bonkers with CPU usage. Tried millions of different tricks to avoid this, the only one which seemed to work was launching chome with --password-store=basic but wasn't really a satisfactory solution. Note that I *didn't* have Chrome Sync set in this instance. Finally, I just launched Chrome, left it idle in the background with gnome-keyring-manager topping CPU while using Firefox in the meantime. Guess what? After ~15 minutes-odd it just stopped doing whatever it was doing and I was able to re-launch and use Chrome as usual. Really odd.

adlorenz: The fix I'm working on (it's a big change, taking a while) won't address the underlying slowness, but it will make it so that it can't cause deadlock nor should it make everything unresponsive while the slow operations are going on in the background.

I'm curious about your keyring though. How large is it? (Look in ~/.gnome2/keyrings for it.) About how many entries are in chrome://settings/passwords?

adl@v3350 ~ $ ll ~/.gnome2/keyrings
total 2536
-rw-rw-r-- 1 adl users       5 Nov  9 17:02 default
-rw------- 1 adl users 2587336 Nov 10 12:27 login.keyring
-rw------- 1 adl users     207 Jul 22 08:57 user.keystore

Hard to tell about number of passwords in chrome://settings/passwords but using Gnome's keyring manager UI I can see 2249 keys. Lot of them seem duplicated, tough.

Patch nearing completion to move GNOME Keyring access out of process:
http://codereview.chromium.org/8509038

adlorenz: How many profiles do you use? Have you been using many different profiles, or deleting and recreating them perhaps?

Which profiles do you mean, Chrome profiles? If so, I have two - personal and work profiles. I never intentionally deleted/recreated them.

I am having this issue with Ubuntu 11.10 with only one password in my key ring, the one for my Google account. Syncs fine if I uncheck passwords but as soon as I try to sync passwords it breaks. It use to give me the spinning loading thing forever but now it will tell me it's synced, but my passwords list is empty and when I close it and open it up again it tells me "Oops! Sync has stopped working". I don't think it has to do with the size of the keyring like in the thread title.

What's the milestone on this?

Let's try for 18. I have a big CL that moves GNOME Keyring out of process in review, but it'll require some more work before landing it. (In particular, there's some question of whether we should use the IPC library for this, or the stdio-based approach I have in my CL now.)

This bug was causing Chromium to crash immediatly after opening (my homepage is gmail login page)

For what fixed it for me:
http://askubuntu.com/questions/88783/why-does-chromium-crash-within-seconds-of-starting/88794#88794

Moving to M20, feel free to move back if you plan to get it in sooner.

 Issue 116656  has been merged into this issue.

Sigh. I have a fix for this but it needs to be rewritten in a somewhat different way. I'll try to get that done soon.

This bug seems specific to the gnome-keyring-daemon version. I'm seeing it with Ubuntu 12.04, which unfortunately means chrome/chromium are unusable by default on 12.04 for me.

Just to clarify, I *don't* see this on Ubuntu 11.04.

M20 is about to sail. If this still need to be part of M20, put them back and add release block label.

 Issue 131862  has been merged into this issue.

Moving all non essential bugs to the next Milestone

This also happens on Debian wheezy with gnome-keyring 3.4.1

Moving all non essential bugs to the next Milestone

Upgraded to Ubuntu 12.04 from 11.10 and am no longer experiencing this issue.

Since the bug has moved few times, removing the milestone label. Please target the right milestone.

Is there anyone on the passwords side who can pick up where Mike left off here?  This issue has been around for a very long time, and I get the feeling Mike is swamped with other work.

P1 bugs that have been moved 3+ times. Downgrading to P2

Bugs that have been moved 5 or more times. Removing Mstone label.

Bugs that have been moved 5 or more times. Removing Mstone label.

Issue 141430 has been merged into this issue.

I've reverted to using plain-text storage for my passwords (--password-store=basic) because of this issue. I understand that part of the blame lies with gnome-keyring-daemon but is there really nothing that can be done on the Chromium side? This is one of the most frustrating bugs I've had to deal with in recent years...

None of the solutions I saw anywhere on the web worked for me.  What did work was to log out of my google account and then log back in.  Seems that when one logs out, some junk in the chrome settings folder gets cleared.

using Ubuntu 14.10 still buggy, chrome ui no more hangs but passwords unavailable for 5-10 minutes while gnom keyring eats a whole cpu core

the best solution for now ( not secure) is to use a plain file to store with 
--password-store=basic

I'm also experiencing this issue and have been for a couple of years now. It's terribly frustrating! Can someone give us an update on any progress on this issue please?

htpc@htpc:~$ google-chrome --version
Google Chrome 42.0.2311.90 
htpc@htpc:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.2 LTS
Release:	14.04
Codename:	trusty
htpc@htpc:~$ uname -r
3.13.0-39-generic

The real answer to this question is that almost every Google developer
tests on Mac OSX and NOT Linux, thus you have lots of Linux deficiencies
that go unnoticed and unfixed. Google would need to employ more Linux devs
/ QA people, but they do not put that much priority on it. It's similar to
Google Drive for Linux, which will never come because most Google
developers don't actually really uses Linux as their primary OS...

Vadym, did your libsecret migration become the default, yet?

Yes, libsecret is used now by default from M42 for storing passwords, but libsecret is only a client for Gnome-keyring service. Using libsecret should fix dead locks that were before and make Chrome part of saving/retrieving passwords faster, but it doesn't change anything on gnome-keyring part.
I'll investigate this issue.
Correctly did I understand that the main problem that passwords are not available long time when Chrome is making sync of passwords on startup? How many passwords are in keyring?

Hundreds of passwords - 350pws makes chrome hand like 1 minute

I've made some investigation of this issue. The problem is that Gnome-keyring service works really slowly on update of changed password records (about 0.1-0.2 sec for each record). But it's only for changed records, and usually there are not so much of them. In Chrome before M42 on Linux there was a bug that caused more frequent update of synced password records that it's needed. Now it should work normally (but it may be still slow on the first start of M42).
Could anyone please check this issue in M42 not on the first time start of it? If it's still here, is Chrome unresponsive or only passwords are not available?

Chrome has become extremely slow on startup after last update (current version  42.0.2311.90 (64-bit)). Gnome-keyring daemon consumes 100% of CPU

 Issue 482590  has been merged into this issue.

I've figured out what are the problems with M42.
In M42 on  Issue 355223  it was implemented switching from gnome-keyring to libsecret library as client for gnome keyring service. Gnome keyring library requires to use only main thread (i.e. UI thread of browser process) to talk with Gnome-Keyring service. So we did a lot of switches form DB thread to UI thread and backward. That of course is inefficient, but it doesn't block any thread (but it causes sometimes deadlock crashes). There is no problem with deadlock in libsecret implementation, since everything is done on DB thread, but it blocks DB thread for time of syncing. 
Also in M42 it was fix bug with serializing of passwords in gnome-keyring service. Before M42 passwords may be synchronized on each startup, even if they weren't changed, now full syncing should be only the first run of M42 or sign in in another account on Chrome.
I'm going to hanging DB thread by reposting syncing task on DB task runner in order to allow other tasks to be processed. I currently don't have time to do this. I hope to make it in June.

 Issue 395489  has been merged into this issue.

Has there been any luck on finding a fix for this? I'm still noticing a lot of CPU usage by gnome-keyring-daemon when running chrome, as well as a lot of disk writes (according to iotop). I worry that this eats away at the lifetime of my SSD.

bendavis78: Could you please give more information? 
1.Which Chrome version do you have? (you can see it by typing chrome://version in omnibox)
2.When are you noticing high CPU usage by gnome-keyring-daemon? On Chrome startup? on syncing new account? 
3.How many passwords do you have? Do you use syncing of passwords?
4.Does Chrome hang during high gnome-keyring-daemon CPU usage?

 I'm planning to work on fixing the problems with gnome-keyring-daemon in July/August.

@dva... 

1. Chrome version: 44.0.2403.30
2. The issue occurs on the first chrome startup (ie, no background chrome processes running). For me, I think it's really more of a problem of i/o. I have sufficient CPU power for it to not be a problem (core i7), though I imagine on slower computers CPU could be an issue. 
3. I have over 400 passwords according to passwords.google.com. Yes, they are sync'd
4. Chrome doesn't hang for me, though I have sufficient memory and CPU to handle the load (core i7-5500U @ 2.4Ghz, 16G ram).

I did a quick test by watching /proc/<pid>/io for the gnome-keyring-daemon process. Before starting chrome, written_bytes stayed at zero. Once I started chrome, I was prompted for my keyring master password, and it wasn't until after I unlocked my keyring that the writes started to happen. It wrote nearly 2.4GB to disk (without increasing overall disk usage) over the course of 4 minutes. Here's the end result:

rchar: 388010429
wchar: 2465164559
syscr: 12932
syscw: 21764
read_bytes: 0
write_bytes: 2470707200
cancelled_write_bytes: 0

As a workaround (and to help save my irreplaceable laptop SSD from an early death), I'm going to try mounting my keyring in tmpfs during bootup and periodically rsync to the drive.

After years of suffering from this, it's finally solved in 43.0.2357.81 Ubuntu 14.04 (64-bit) for me after I upgraded from Chromium 41.x. Heureka! Thanks :)

@bendavis78: Thanks for detail information. This is surprisingly high data for writing by gnome-keyring-daemon process. We store only about 1 kb data in gnome-keyring per password, so even if all passwords were updated on sync (but all passwords are updated only on the first sign-in in Chrome), it's less then 1 Mb for all passwords. I've checked on my workstation, /proc/<pid>/io shows a little bit more than 1Mb on one password update, that's less than in your case, but still a lot.
 I'm not sure that we can do something with much data writing by gnome-keyring on one password update, but probably we can decrease number of updates. Could you please make an experiment? Turn off please synchronization of passwords (in chrome://settings/syncSetup ), and check if gnome-keyring still writes a lot of data after startup. 

Finally someone is doing the job Google / a chrome team should be paid to
do...awesome stuff Ben. Maybe They should just hire you and fire one of
their own QA staff since no one really ever stress tests Linux releases
inside of google...

Same version of chrome - still getting 100% CPU on that process... Any idea how to get rid of it (I mean other than switching to Firefox)?

Good call. Yeah I've been planning to switch back to Firefox too. It's
about time to do that...

Chrome's marketshare is about 50% , so it doesn't give a **** about Linux users' (1%) problems. It's a pitty, but true. Threating to drop Chrome is irrelevant too, cause you will be still searching using Google, Google won't lose any penny.So let's consider on the bug.

not consider, focus

No. Google doesn't have my queries any longer. I use Disconnect Search and
so should you. You can utilize DuckDuckGo as the proxied engine if you like
-> https://search.disconnect.me/searchTerms/search?query=yourquery

@padcom: I see two temporary solutions to fix slow Chrome startup:
1. Use a flag --password-store=basic, but please take into consideration that in this case all passwords will be stored in a non-encrypted database in your home directory (that of course not nice from security perspective)
2.Turn off password syncing (you can do it on a page chrome://settings/syncSetup), that should be ok from security perspective, but of course may be not so convenient.

@dva...

Yes, disabling password sync does keep this from happening. For now I'm currently using anything-sync-daemon to mount my keyring dir in tmpfs, and that seems to do the trick with regard to preventing disk writes. It still uses high CPU, but not so much that my Pixlel2 can't handle it. It'd still be nice to know why having a large keyring causes such an issue.

If Google / Chromium team doesn't know why this is happening, it is also
possible that some type of malicious backdoor in Chrome exists that is
siphoning the keyring...

bendavis78: Thanks a lot, the problem is in synching as I thought. I'll try to fix it.

kristian.hermansen: Currently we don't have here any suspicions on mailware. There is a combination of reasons of this behavior, namely 1) A bug in syncing, that causes for some users resynching of passwords on each startup and 2) Keyring service is pretty slow. 

i can confirm this problem tih google chrome but not with chromium ... strange

>I hope to make it in June.
It's end of July, still no fix, still high CPU load. When?

No one cares about linux dude

For those who are f*** up with this bug - try KeePass (or KeePassX)! Really handy open source solution. Your password are not leaking to Google anymore, you are not tied to any platform. Autoinsert is supported
To transfer password from chrome2keepass.rb by Alan Laudicina  github.com/alanpca/chrome2keepass

Or try http://masterpasswordapp.com/

Or try http://masterpasswordapp.com/

@dva... Has there been any progress on this issue? I would report an issue to Gnome, but I'm not sure I understand what's causing the issue in the first place.

@bendavi...@gmail.com: Sorry, I didn't manage to figure out what's causing that on your machine so many keyring password entries are updated in keyring on sync. Another problem is that gnome keyring is very slow and writes so much data on disk, but probably it's just how it works. 
We have plans to restructure all linux passwords backends in order to avoid such problems, but we will have resources only in 4-6 months.

Still a problem on 50.0.2661.102, so I assume the rewrite of the Linux password backend hasn't happened yet.  Very much looking forward to it.  Excited for this years-old paper cut to finally heal :).

Yes, we have too much to do and to few people :).
However, a colleague recently started to prepare the encryption backend for Linux in  bug 602624 , and once done, we can finally start removing the password storage backend (bug 571003).

I remove my ownership, since this issue will be fixed by implementing new password backend on  bug 602624 .

The tracking bug for removing Gnome keyring integration is bug 571003.

Actually, because this will be fixed by fixing bug 571003, let's close it as WontFix.

Can you remind me where are passwords stored if I run browser with --password-store=basic ? I would like to remove them

They stored in files <User Profile path>/Login Data, <User Profile path>/Login Data-journal. You can find <User Profile path> by typing chrome://version in Chrome address bar and looking for "Profile Path".
Please note that after implementing of bug 571003 encrypted passwords also will be stored in this file.