This may become problem for our own internal users which require policies to be relatively fresh. Additionally, there is a risk that infrequent use can make this more out of sync. Upgrading to P2 for now.

Mattias: Is it possible that you don't logout/login and instead rely on sleep/resume ? I wonder if there is a correlation of this getting out of date only on those devices on which users don't logout/login.

+Chris to take a look.

Clarification: I did indeed not log out and back in (this restarts Chrome and causes a policy refresh), but instead just resumed and unlocked an already-running session.

We have another internal googler confirmation about this behavior. Based on my understanding the device should aggressively get updates within a short period of time... the fact that it didn't get it makes this a bad bug for enterprises where we have 1:1 device to user mapping (where users don't logout).

I'm moving to P1 for visibility and triaging. Not clear if this is a client side or a server side bug as of now.

Any progress on this? We are nearing 55 stable and this is marked as a blocker, if we can get a fix in the next two days we can make the targeted RC, if not we may have to punt or delay. 

Drew: Can you help us find an owner for this. We suspect its a client side bug based on available data.

Mattias, what does about://policy say your refresh interval is? I didn't see your about://policy screenshot -- do you still have it?

Something odd is happening with the logs, btw:

[1:1:1110/172544:ERROR:KeyboardEventManager.cpp(424)] Not implemented reached in static bool blink::KeyboardEventManager::currentCapsLockState()
[31155:31162:1115/000722:WARNING:screen_manager.cc(101)] Display controller (crtc=20) already present.
[31155:31162:1115/000722:VERBOSE1:drm_display.cc(102)] DRM configuring: device=/sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc=20 connector=29 origin=0,0 size=2560x1700
[1:1:1115/090738:ERROR:WebRemoteFrameImpl.cpp(192)] NOTREACHED() hit.

I see two log lines around midnight on Nov 15, then only about 10 seconds of logs on Nov 15th:

[1:1:1115/091813:ERROR:WebRemoteFrameImpl.cpp(192)] NOTREACHED() hit.

How long did you use the device after waking it up? It's possible that maybe the device somehow didn't realize the time had changed (seems weird to me)? But I don't know how to explain only 10 seconds of logs, because that wouldn't give you enough time to notice that the device hadn't made a policy fetch, grab logs, etc.

Royans, please link me to the other googler report about this. +igorcov: do you have cycles to try to repro this?

Drew: just added u to an internal thread.

I've reproduced this on a reks device, using the latest sources (version 57). The fetch interval shows to be 1 day for both, device and user policies and user policies have auto-updated after 24 hours, while device policy have not.

Igor take a look once you're done with your P0s.

Given this is a Pri-2 issue, should we really block stable on this?

based on comment #5 it should be a P1

Ok, we are looking at delaying our 55 stable to try to get fixes for this and a couple other blocking issues, the sooner we can get a fix in place the better.

I don't believe this is a blocking issue - if the policy changes, then we'll get a GCM notification to prompt us to fetch policy (the 24 hour policy fetch interval is just a backup). It's only an issue for google.com because of the inexplicable choice by netops to require devices to check in for policy fetches even though policy itself hasn't changed, but I don't think we should be holding up stable releases for that.

Anyhow, Igor is working on other P0s/P1s and won't get a chance to look at this until early next week.

SGTM, thanks!

I will have to delay this, as another P0 appeared that has to be fixed in 57 (https://bugs.chromium.org/p/chromium/issues/detail?id=673270)

The reason for this problem happening is that TimeTicks (used to manage the time)
doesn't count the time spent while the device is asleep. So, the refresh interval
should be read as 24 hours of active non-sleeping time on the device.

There's a CL in review that checks also the system time when the device is woken
up and refresh if necessary. This change will not assure a good accuracy, but it
will guarantee a real refresh interval no bigger than twice the displayed value.
Assuming the user doesn't change the system time manually.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5d10b590e88508313c9e68d004cabc11bf6f55ce

commit 5d10b590e88508313c9e68d004cabc11bf6f55ce
Author: igorcov <igorcov@chromium.org>
Date: Mon Feb 27 14:25:15 2017

Device policy refresh fixed when the device is woken up.

When the device wakes up, check and reschedule, if the policy refresh should happen earlier based on system time.

BUG= 665343 
TEST=Manually tested on lulu device.

Review-Url: https://codereview.chromium.org/2638923002
Cr-Commit-Position: refs/heads/master@{#453207}

[modify] https://crrev.com/5d10b590e88508313c9e68d004cabc11bf6f55ce/components/policy/core/common/cloud/cloud_policy_refresh_scheduler.cc
[modify] https://crrev.com/5d10b590e88508313c9e68d004cabc11bf6f55ce/components/policy/core/common/cloud/cloud_policy_refresh_scheduler.h
[modify] https://crrev.com/5d10b590e88508313c9e68d004cabc11bf6f55ce/components/policy/core/common/cloud/cloud_policy_refresh_scheduler_unittest.cc

Verified in Candy Device in M58. Device Policy refresh looks ok.

M	ChromeOS	Chrome	ARC	Type	Channel
58	9334.3.0	58.0.3029.6	(multiple)	release	dev