Logs: https://storage.cloud.google.com/chromiumos-test-logs/cr_666430/log-111716-114906.tar.gz

Omri, please assign to Dev for fix.

We'd ideally not be releasing any builds with this bug present, hence tagging with ReleaseBlock-Dev.

govind, bhtompson to CC for visibility.

For 55 we are well into beta, and almost into stable, so a dev release block does not really make sense (we don't even generate 55 dev channel builds anymore). 

Assuming this is already in the current beta, we can mark this as a stable blocker.

This is specific to Chrome OS, so it won't be a blocker for Chrome Desktop, correct?

Wrt #5: Yes, the ChromeOsLockOnIdleSuspend policy only affects Chrome OS.

Note: If Admin sets "Idle time in minutes" blank, then the "Delays":"Idle" properties are not set and the idle time becomes the system default of 15 minutes, and screen locks on idle as expected. Thus, this bug seems to happen only when the Admin actually specifies an idle time.

Should assigned for fix.

Albert, who should own this bug?
(assigning to me for now so that it doesn't get lost).

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. 

Ping for update, if this is really a blocking issue we need a fix ASAP, our R55 stable RC is going to build in a few hours, and this may cause it to be invalid so we can delay :(. 

Observation: CrOS user sessions will Lock on Idle after 10 seconds when the ScreenLockDelays policy is set as follows (using YAPS):
{'ScreenLockDelays': {
    'AC': 10000,
    'Battery': 10000
}
But the ScreenLockDelays policy is not exposed in the CPanel; it's not 'hooked up' to any User Setting on the CPanel, so Admins cannot control it. It always defaults to Not set. 

Even so, the expectation is that the following ChromeOsLockOnIdleSuspend and PowerManagementIdleSettings policy values should invoke Lock on Idle after 10 seconds:
{'ChromeOsLockOnIdleSuspend': True},
{'PowerManagementIdleSettings': {
    'AC': {
        'Delays': {
            'ScreenDim': 6000,
            'ScreenOff': 8000,
            'Idle': 10000
        },
        'IdleAction': 'Suspend'
    }
}
Chrome OS's disregard for PowerManagementIdleSettings is what needs to be fixed.

Argh! Got CCed on this while I was on vacation and missed it.

Bouncing this between a few PMs isn't going to fix it.

steel@ can someone on your team take a look at this?

This is marked as a regression, so does that mean that this was not happening on M-54?

Correct. It was working in M54 (at least, it works fine when on my Google-issued personal device, running Stable M54).

We have deferred our 55 stable promotion to next Tuesday, so if this is remaining as a blocker we need a fix by Monday evening (or earlier if this is a browser side fix). 

Scott, what happens on an unmanaged device - I think the user can still set their device to lock-on-idle. Does this work?

I'm trying to figure out if this mechanism is broken entirely or if it's just at the enterprise layer, because the enterprise code is pretty straightforward (just sets the same pref that is exposed via settings ui).

FWIW, my google-com enrolled M56 laptop seemed to lock just fine when it went idle, with the following settings:

ChromeOsLockOnIdleSuspend: true

PowerManagementIdleSettings: {
  "AC": {
    "IdleAction": "Suspend"
  },
  "Battery": {
    "IdleAction": "Suspend"
  }
}

I did this by just leaving my device idle for several minutes until the screen shut off, then touched the trackpad (within a few seconds of the display turning off) and the display came on and showed the lock screen.

Wrt #19, #20:
1) Yes, "Require password to wake from sleep" check box works as expected on consumer devices. It also partially works on enrolled devices (set by ChromeOsLockOnIdleSuspend=True), when the blank idle delay is used, which defaults the Idle time to 15 minutes. What doesn't work is when the admin sets the idle time to something other than blank, such as 5 minutes.
2) Yes, that's how an admin would enable suspend on idle, using the default delay of 15 minutes (or whatever is built-in for the device under test). What does't work is when the Admin enters a value for "Idle time in minutes", less than 15 minutes. E.g., 1 minute, or  'Idle': 60000.

Toni could you pick this up and look at this at a priority?

OK, updating the summary to make it clear that ChromeOSLockOnIdleSuspend policy works just fine, it's that non-default idle timeouts don't seem to work (I'm guessing the device isn't actually going into idle state to trigger the suspend - we're just getting the display shut off).

+derat, who should be more familiar with cros power manager

Looking at logs in comment #1, it looks like power manager uses no-op as idle action (rather than suspend) [1] - that would explain why the screen is not locked when device goes idle. The device does not really suspend; and lock screen is set in response to suspend imminent signal. 

I can reproduce the same behaviour on my dev machine (idle action set by Chrome policy being ignored by power manager), and this seems to be caused by idle suspend being disabled in power manager prefs (in particular by content of /usr/share/power_manager/disable_idle_suspend being set to 1).


Note that in the case idle delay is not set by policy (config from comment #20), Chrome's policy controller will ensure screen lock delay (ac_delays.screen_lock_ms in PowerManagerPolicy protobuf) is set [2] - I assume this is what causes the screen to lock on idle in that case (I haven't yet looked too much into this on power manager side)

[1] Extract from the powerd logs:
Updated settings: dim=1m screen_off=1m lock=0s idle_warn=0s idle=1m (no-op) lid_closed=suspend use_audio=1 use_video=1

[2] https://cs.chromium.org/chromium/src/chromeos/dbus/power_policy_controller.cc?rcl=0&l=212

/var/log/power_manager/powerd.LATEST should show what powerd is thinking. I'm happy to take a look if you attach a log file and mention the time at which the problem occurred. I don't think that Chrome's code for passing these prefs to powerd or powerd's handling of them has changed in a long time (maybe ~2 years), but I can't speak to the policy side of things.

Dev builds set /usr/share/power_manager/disable_idle_suspend to 1 (due to overwhelming developer demand). Remove that file or change it to 0 if you're trying to test the behavior in production. Looking at the powerd log from the initial report, I'm guessing that you're using a system that has disable_idle_suspend set to 1.

Note also that the screen turning off isn't the same thing as "sleeping". Sleeping means suspending, i.e. the system goes into the S3 power state. If the "require password to wake from sleep" pref is set, Chrome will lock the screen before powerd suspends the system, but just waiting for the screen to turn off isn't equivalent.

There are various things that can lengthen delays (I refer again to https://www.chromium.org/chromium-os/packages/power_manager/inactivity-delays). There are also policies that can be set to disable these things. I can't give more info there without seeing logs.

One other thing to note: if the "require password" pref is set, Chrome will also lock the screen ten seconds after turning the screen off. This is done since there's a long delay by default between the screen turning off and the system suspending, and it's weird to spend a lot of time in a state where the screen is off but the user doesn't know if their system is locked or not.

(TL;DR my guess is that there's no regression here and you're just seeing different behavior as a result of using a dev or test image.)

Yes, my current guess is as well that this is a result of using dev/test image.
(logs are in comment 1 - It looks like powerd receives ac_idle set to suspend from Chrome, but state controller converts that to no-op).

I'm happy to make powerd log something when disable_idle_suspend is set, since it's certainly unclear just from looking at the logs why the action supplied by Chrome is being ignored.

Looking through policy/state_controller.cc code, it seems two cases this might happen are
* when idle suspend is disabled
* when updater is in UPDATING state.

+scunningham, who reported the bug and supplied logs in #1 - would you be able to verify whether disable_idle_suspend was set on the device in question
(/var/lib/power_manager/disable_idle_suspend or /usr/share/power_manager/disable_idle_suspend), or whether this repros when /var/lib/power_manager/disable_idle_suspend is set to 0

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/d41cdce96f9c07951784f47585c7c9cedc17a542

commit d41cdce96f9c07951784f47585c7c9cedc17a542
Author: Daniel Erat <derat@chromium.org>
Date: Sat Dec 03 01:07:04 2016

power: Log a few more cases when the idle action is ignored.

Make powerd log an informative message when the default idle
action is ignored due to the disable_idle_suspend pref being
set (as happens automatically in dev/test images) or an
update being applied while on AC power.

These overrides happen when powerd is computing its
settings, so while it was possible to see that the
Chrome-supplied action was being ignored in the current
logs, the reason why was non-obvious.

BUG= chromium:666430 
TEST=manual: used set_power_policy to set a 1m idle delay,
     then watched the logs and saw "Not performing idle
     action because disable_idle_suspend powerd pref is set
     (done automatically in dev)"

Change-Id: If95b78d2a74ed3645c6b10d0ea737b0af2653401
Reviewed-on: https://chromium-review.googlesource.com/416374
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Toni Barzic <tbarzic@chromium.org>

[modify] https://crrev.com/d41cdce96f9c07951784f47585c7c9cedc17a542/power_manager/powerd/policy/state_controller.cc
[modify] https://crrev.com/d41cdce96f9c07951784f47585c7c9cedc17a542/power_manager/powerd/policy/state_controller.h

Scott, can you repro this with the steps described in comment 29?

Also, if we don't have a fix today this will be a day by day slip on the R55 stable schedule .

(Or better, just try to repro it on a non-dev device, assuming that that's what was going on.)

Krishna, would you do this (per #33 - #34)?  I won't have my workstation at my new desk till Thursday.

Removing release block stable as this is not believed to be a regression.

Was not able not repro this on a device with a recovery image(ie, a non-test image build.) 
The scrren lock on idle worked even when setting the idletimeout to a non-default vaue (eg, 1min.) 
Closing this, will reopen if we see this issue.