There's a 'wait_for_initial_user_activity' field that Chrome can set in the policy that it sends to powerd:

  // If true, instructs the power manager not to perform any
  // delay-triggered actions while in a user session until user activity
  // has been observed. After activity is seen, the inactivity timeout
  // starts. The actions are deferred again after a new session starts.
  // Note that this has no immediate effect if activity has already been
  // seen within an already-started session (activity that took place
  // before the policy change is honored) and also that it has no effect at
  // the login screen.
  optional bool wait_for_initial_user_activity = 12;

I don't know Chrome's logic for deciding to set that offhand, but perhaps it's enabled here. (Maybe this behavior is intentional for public sessions.)

@sduraiswamy, any idea if the behavior described in #c1 was by design. 
 

I do not think that is the intended behavior. The session timer should start irrespective of user activity.

Vidya, adding you in case if that was the intended behavior.

See  issue 310176  for earlier discussion.

I'm a bit confused about "Log on to public session, _do not move mouse or touch keyboard_, wait for 1 minute." How do you log on without using the mouse or keyboard?

I'm guessing they mean don't touch them *after* starting the public session.

Do we really care about this issue? Tempted to wontfix.

IIRC the reason for this policy was that we didn't want to periodically end sessions on demo devices that nobody was interacting with. I think that autologout is mostly there to handle cases where a user signs into a privileged account and then walks away from the device. If the user hasn't interacted with the device after starting the session, I'm not sure what we're trying to protect against.

marchuk@, please attach /var/log/power_manager/powerd.LATEST right after you see this (immediately soon after booting the system, too) so I can make sure that wait_for_initial_user_activity is set. I'm assuming that that's why you're seeing this behavior, but it'd be good to know for certain.

attached, yes it's set to 1

Deleted: powerd.LATEST 17.1 KB

powerd.LATEST 17.1 KB Download

Thanks. Yep, this is working as intended:

[0406/094923:INFO:daemon.cc(1359)] Received updated external policy: ac_dim=0s ac_screen_off=0s ac_lock=0s ac_idle_warn=40s ac_idle=1m battery_dim=0s battery_screen_off=0s battery_lock=0s battery_idle_warn=40s battery_idle=1m ac_idle=logout battery_idle=logout lid_closed=logout use_audio=0 use_video=0 presentation_factor=1.0 user_activity_factor=1.0 wait_for_initial_user_activity=1 force_nonzero_brightness_for_user_activity=1 (Prefs)
[0406/094923:INFO:state_controller.cc(757)] Updated settings: dim=0s screen_off=0s lock=0s idle_warn=40s idle=1m (logout) lid_closed=logout use_audio=0 use_video=0
[0406/094923:INFO:state_controller.cc(768)] Deferring inactivity-triggered actions until user activity is observed each time a session starts

Feel free to reopen if the thinking has changed and we no longer feel that public accounts should use this (which will presumably just require making some change on the policy side).