System suspends instead of shutting down if lid closed after shutdown requested from system tray |
||
Issue descriptionPer an email thread about http://feedback/product/208/neutron?lView=rd&lReport=53420086784, it looks like there's a race where the system can suspend instead of shutting down if the lid is closed right after shutdown is requested via the system tray rather than via the power button. powerd suspended due to the lid being closed at 06:07:01 on the 15th and both resumed due to the lid being open and received a shutdown request from Chrome at 05:29:58 on the 16th: [0215/060700:INFO:daemon.cc(507)] Lid closed [0215/060701:INFO:main.cc(259)] Running "/usr/bin/powerd_setuid_helper --action=suspend --suspend_wakeup_count_valid --suspend_wakeup_count=170" [0216/052958:INFO:daemon.cc(693)] powerd_suspend returned 0 [0216/052958:INFO:daemon.cc(1140)] Got RequestShutdown message from :1.7 From the Chrome log: [1384:1384:0215/060701.194344:VERBOSE1:lock_state_controller.cc(300)] OnRealPowerTimeout Chrome logs this when it asks for the system to be shut down, so we can see that Chrome decided to do this right as the system was suspending on the 15th. I suspect that something like this happened: 1. The user clicked the shutdown button in the system tray. 2. While Chrome was still displaying the fade-to-white shutdown animation, and before it had asked powerd to shut the system down, the user closed the lid, causing powerd to suspend the system. 3. When the user opened the lid later, Chrome woke up and immediately asked powerd to shut down, which it did. powerd avoids suspending in response to the lid being closed if it's already in the process of shutting down, but it can't do that if Chrome hasn't told it to shut the system down yet, as seems to be the case here. The problem here appears to be that Chrome has decided to shut the system down, but it hasn't told powerd yet because it wants to display the shutdown animation (and possibly announce it for a11y) first. If this is indeed what's happening, I bet we could work around it by having Chrome clear the lid-closed policy even earlier when it knows it's going to shut down soon.
,
Mar 4 2017
My first thought here was to make ash::LockStateController call chromeos::PowerPolicyController::Get()->NotifyChromeIsExiting() as soon as it decides to shut the system down. I did that, and wrote some tests... and then I realized that PowerPolicyController isn't instantiated in mash. PowerPolicyController currently combines power-management-related browser prefs, wake locks, and miscellaneous other state into a policy that gets sent to the power manager. Since some of that state comes from the browser and other parts from ash, this actually opens a huge can of worms. I probably need to open a new bug and/or write a design doc to think about this more. It'll probably involve either adding IPC between processes in mash (I'm not even sure where the core policy should be constructed and sent) or completely restructuring the policies that are sent to powerd so that it can combine policies from multiple sources.
,
Mar 7 2017
FYI: jonross@ implemented a preferences service where mash can subscribe to preference updates from chrome browser. Maybe that could help?
,
Mar 7 2017
Is that preferences/public/interfaces/preferences.mojom? I'm not sure that I can use it here; having ash know the names of Chrome prefs feels like a layering violation. Is the current plan for most D-Bus client code to live inside of the mash process? If we do need a "power management policy" service that essentially duplicates chromeos::PowerPolicyController's public methods to make them accessible to both Chrome and mash (ugh, I am so not excited about that), where should it live?
,
Mar 7 2017
Sadly, I think you are the best person to make these decisions. :-) Generally: * It feels to me like power management should live in ash. Someday it would be nice to be able to run without chrome. * Could the pref names be moved into ash/public? If they are "low level" then chrome could depend on ash for them. * Can power manager have multiple dbus clients talking to it? I'm guessing no, since it sounds like this must bundle up a bunch of stuff at the same time, but maybe that could change? * If we have to have a power policy mojo service it seems like it should be implemented in //chromeos somewhere and instantiated in ash. HTH
,
Mar 17 2017
I've filed issue 702449 to track the power policy refactoring that needs to happen for mash and that blocks fixing this. |
||
►
Sign in to add a comment |
||
Comment 1 by derat@chromium.org
, Mar 4 2017