My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 99907: Doesn't look like Sync immediately restarts if you re-enable sync by policy
4 people starred this issue and may be notified of changes. Back to list
Project Member Reported by, Oct 11, 2011
What steps will reproduce the problem?
1. Disable sync via the management layer
2. Re-enable sync via the management layer (remove the "disable sync" directive)

What is the expected output? What do you see instead?
Expected: sync starts up again (on chromeos)
Actual: I don't think sync will start up until the user restarts his device.

Note this code:

void ProfileSyncService::OnSyncManagedPrefChange(bool is_sync_managed) {
  if (is_sync_managed) {
  } else if (HasSyncSetupCompleted() && AreCredentialsAvailable()) {

DisableForUser() will clear the SyncSetupCompleted flag. That means when sync is no longer managed, we won't call StartUp().

I suspect this clause should be "if (!HasSyncSetupCompleted() && AreCredentialsAvailable())" (i.e. call StartUp() if sync isn't already running). 

Oct 12, 2011
(No comment was entered for this change.)
Status: Assigned
Oct 12, 2011
I tried the change suggested by atwilson, but unfortunately that doesn't do the trick. I checked with the debugger and found that AreCredentialsAvailable() returns false, even if the sync had been active before, then disabled through policy and enabled again.

Since I'm not familiar with the sync authentication code, I don't think I'm the right owner for this, anyone keen on taking it? I'm happy to provide guidance regarding setting policy for testing.
Oct 12, 2011
I don't really have cycles to look at this right now - maybe either Fred or Richard might?

The logic in AreCredentialsAvailable() is pretty simple:

bool ProfileSyncService::AreCredentialsAvailable() {
  if (IsManaged()) {
    return false;

  // CrOS user is always logged in. Chrome uses signin_ to check logged in.
  if (!cros_user_.empty() || !signin_->GetUsername().empty()) {
    // TODO(chron): Verify CrOS unit test behavior.
    return profile()->GetTokenService() &&
  return false;

So what I think is happening is SigninManager::SignOut() is blowing away the tokens in the TokenService, so when we try to restart sync, there aren't any tokens any longer (I bet if you restart chromeos in between disabling sync and re-enabling that it would work).

I don't quite understand how the token service gets its tokens on chromeos - comments in ProfileSyncService::Initialize() imply that there's some special plumbing ChromeOS does.

I can think of two options:

1) Change SigninManager::SignOut() to not blow away the tokens in the token service on ChromeOS.
2) Add code to re-initialize the tokens in the token service on chromeos when sync is re-enabled.

I haven't looked into it enough to know how to do #2. I'd probably lean towards #1.
Jun 7, 2012
(No comment was entered for this change.)
Status: Available
Owner: ---
Labels: SyncHackathon5Candidate OS-Chrome
Jun 8, 2012
(No comment was entered for this change.)
Labels: Feature-Enterprise policy
Jun 8, 2012
OK, I understand this better now :) The token service thing was a red herring, since we don't blow away tokens on cros.

The problem actually was that when we shut down sync, we blew away the bootstrap token so we wouldn't be able to restart sync due to encryption issues (we need a user password to encrypt/decrypt sync data).

Kochi has done some work in this area to allow re-enabling sync via the settings uI without forcing a login - the remaining problem is that if we have *never* started sync (if sync was already disabled at first login) then we still don't have any way to encrypt or decrypt data until the user enters his password at the next login.

We are migrating to an encryption solution that uses a server-provided key - once that is in place, we ought to be able to do this because then sync can bootstrap itself without requiring a user-provided passphrase.
Jun 19, 2012
It sounds like this depends on server key encryption?  If so, probably not a good hackathon bug.
Labels: -SyncHackathon5Candidate
Oct 25, 2012
(No comment was entered for this change.)
Labels: Sev-2
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-Internals -Feature-Sync -Feature-Enterprise Cr-Enterprise Cr-Services-Sync Cr-Internals
Mar 28, 2014
(No comment was entered for this change.)
Labels: -Sev-2 Enterprise-Triaged
Mar 31, 2014
This policy is deprecated - admins should disable sync via the dasher console (disable at the server) rather than disabling via local policy.
Status: WontFix
Sign in to add a comment

Powered by Google Project Hosting