I hadn't thought of users who just do long press. Makes total sense that some users would do that.

When I try it in 50.0.2657.0 though it actually LOOKS like it does a proper shutdown. It logs out, goes back to the start screen, then does the fade to white I expect with a double press.

It might make sense to just make sure the shutdown actually IS proper rather than simply adding a sync.

My suspicion is it's trying to do a clean shutdown but the EC cuts power slightly before shutdown is complete. A slightly longer timeout on the EC might be all that is required.

Initiating a sync() without shutdown would be (relatively) easy to accomplish, and would have real benefits versus simply cutting power.  Initiating a full shutdown guarantees that we'll start a ton of disk activity, so if it does not complete the final sync(), it potentially makes things worse versus simply cutting power.

I guess if it's trying to initiate a shutdown, throwing a sync() in the mix isn't going to improve things!

Mmm, I also just tried on my Pixel 1 and it did do a proper shutdown.  I am not sure that's always been the case.  It took several seconds though, and I had to fight my instinct to lift the finger.

It is possible that the timeout is too short.  In any case it's not clear that the initial sync will make things worse even in the case of shutdown.  It's likely that many of those buffers need to be flushed for other reasons.  The number of buffers that will get flushed twice as a result is probably going to be small.

We should try and measure this first.  It may be that some of our histograms already contain this information.

Mostly what I'm concerned about in #3 is that if we're trying to do a real shutdown, then throwing an arbitrary sync() call in there isn't helpful.  Admittedly, it's probably 23 syncs over here and 24 syncs over there, so it might also not be all that nasty, either.

If there's a delay between press and when it starts to initiate shutdown, though, I'm more interested in sending off a sync() immediately on press.  Because in that case, it's clearing the decks so that the shutdown syncs don't have as much to deal with.

The final sync happens after all processes have ended.  Doing an earlier sync may speed up the final sync.  I am not so worried by the amount of files that Chrome writes at shutdown, I am more worried about the amount of dirty buffers that may have accumulated in a previous operation, like a large download.

There is a significant misunderstanding/confusion regarding how to properly shut down a Chromebook. We have been telling users that holding down the power key is the proper, and safe, method. If this can cause file system problems, it is not documented or warned against.

Acer's support site says to hold down the power button:
http://acer.custhelp.com/app/answers/detail/a_id/10613/~/how-do-i-turn-my-acer-chromebook-on-and-off%3F

As does Samsung:
http://support-us.samsung.com/cyber/popup/iframe/pop_troubleshooting_fr.jsp?modelname=XE500C12I&homeid=408000&from_osc=&idx=531993&modelcode=XE500C12-K01US&

The Google Help Center instructs that holding the power key down is one of the 3 proper methods:
https://support.google.com/chromebook/answer/3420029?hl=en&source=genius-rts

There are other sites telling users to hold down the power key:
http://classroom.synonym.com/properly-shut-down-chromebook-17125.html

I even have it in one of my canned responses for Chromebook Central.

Clarification and/or fix is needed.

Jim Dantin

+Sameer and +Eric for powerd.  Also +Sonny and +Todd because we just discussed this.

Unfortunately I think it is quite possible, especially on lower-powered systems, that holding the power button down will result in unclean shutdown, especially if there are lots of dirty buffers that need to be written back to disk.  This could happen, for instance, after a large download.

The irony is that having few tabs open can potentially make this problem worse, because in such state there is more room for the file cache.

Re: #7  Thank you for the information.

The Acer support site says:

"To power off your Chromebook press the power button for about a second to lock your screen. Keep pressing the power button to completely shut down your Chromebook. If your're on the main sign-in screen, you can click the Shut down button in the lower-right corner of the page or simply close the lid to shut down."

This is almost correct, but not quite.  It should say "Press again the power button" instead of "Keep pressing the power button".

The Samsung site says:

"To power off your chromebook, press the power button for 5 seconds.  The system will shut down."

This is bad.  Five second is fairly meaningless, as the system cannot make any precise time guarantee (except for the 8-second EC power cutoff).

The other two sites suggest pressing the power button for 3 and 3-5 seconds respectively.  Same comment applies.

Re: #10 Pressing the power button twice does not lock the screen - you have to hold it until the sign in screen is displayed, then let go. Properly documented (thankfully!) on this HC page:
https://support.google.com/chromebook/answer/2587994?hl=en&source=genius-rts

Agree that "This is bad."!

What do you say Eric?  Isn't this a delicious bug to fix?  Very high reward/effort ratio.

As always, should you choose to accept this mission, Sameer will disavow any knowledge of your actions.  Your computer will self-destruct in 5 seconds.  Good luck.

Sorry, I wasn't aware a decision had been made on this yet. I can get started on it.

I assigned this to you because I was told that you would like to work on the power manager, but you're part of this decision as well.  I think there is some consensus that an early sync may be a good idea, but nothing is set in stone.

Well, this is small. I'll write it and see if we like it.

Holding the power button continuously through the lock screen has always been the recommended way to shut a Chromebook down. There's always been a risk that the user holds the power button so long that power gets cut before shutdown finishes, but we've tried to minimize it by turning the panel and keyboard backlights off as soon as powerd initiates shutdown, in order to signal to the user that the machine is effectively off at that point and that they don't need to hold the button any longer.

With that said, screen lock performance is so abysmal now (issue 452599, which seems to have the entire Chrome OS team cc-ed) that I think it's a certainty that we often don't even start shutting down by the time power is cut sometimes, particularly on slower systems.

I don't have objections to launching a sync earlier, since it seems pretty harmless, but it's just papering over the underlying issue and is still going to leave us with unclean shutdowns. The firmware power button timeout was chosen based on an assumption about how long userspace would take to shut the system down, and userspace is no longer delivering there.

I've personally never heard this recommendation before, so I was surprised to hear this.   Shutdown times have often been pretty slow based on the numbers that have come out of the bootperf test -- I think 5 seconds for shutdown wasn't unusual on the first Samsung ARM ChromeBook, and we've not spent a lot of time trying to optimize it.  Indeed if there's a lot of dirty data that hasn't been flushed to disk, we can take a long time to sync and shut down due to random writes to eMMC being slow, so IMHO we've been tempting fate by telling people this.

What's wrong with suggesting that we use the UI button for shut down rather than holding the power button?

Re: #17 This is exactly why I documented three sites (there are many more, including in Acer device manuals) that instruct users to press the power button. We seldom know what the developers' design intent is - all we can go on is the documentation, and there is sometimes a disconnect that can cause significant issues.

We were under the impression that holding the power button is simply a shortcut to the same process as the menu's power down icon. We were also completely unaware that holding the button too long would do a forced power cut - we were told the EC Reset (refresh+power) was designed to do that.

A warning popup would be helpful, but I don't think we can reasonably expect to scrub all of the existing published directions.

Re: #17 This is exactly why I documented three sites (there are many more, including in Acer device manuals) that instruct users to press the power button. We seldom know what the developers' design intent is - all we can go on is the documentation, and there is sometimes a disconnect that can cause significant issues.

We were under the impression that holding the power button is simply a shortcut to the same process as the menu's power down icon. We were completely unaware that holding the button too long would do a forced power cut - we were told the EC Reset (refresh+power) was designed for that.

A warning popup would be helpful, but I don't think we can reasonably expect to scrub all of the existing published directions.

Has anyone measured how often this actually happens?

Again, we're not expecting the system to be fully shut down in eight seconds; the screen should just be off well before then (to signal to the user that they can release the button). Eight seconds is a really long time to be holding a button.

Would this be accurate instructions?

"To safely shut down your Chromebook, press and hold the power button for a few seconds until the screen turns off. Then release the power button and the Chromebook will finish shutting down.

If you continue to hold down the power button, a forced power interruption will occur, which may result in data loss."

#21: That's accurate.

To others: is there any way that userspace can cancel the EC's hard-power-off behavior once shutdown has started? I'm guessing not.

Let's see if Gwendal can add one more bit of info.  Gwendal, what is the kernel shutdown timeout waiting for the file system to sync?

#20 I agree with Dan, we need to see if UMA stats measure this, directly or by extrapolation.  Note that this does not correspond to a Chrome "unclean shutdown"; Chrome could be shutting down fine, but power might be still cut off before all buffers are flushed.

#20 second point: 8 seconds may be a long time, but folks may be distracted by all that happens.  First, there is the screen lock animation, then the fade-to-white animation.  If those take longer, it's natural for the user to keep pushing.  Also, is it possible that on some models some LED changes state when shutdown has completed?  If so, then the user might wait for that too.

#16 and #17: I've also never heard the long-press recommendation.  I've always treated it as a two-step operation, first to lock the screen, then to shut down.  BUT (big but), I've always been keenly aware of the 8-second timeout, because we're developers, and before we had the EC reset, it was the standard way of unwedging a system.  I can see that most users would feel it natural to just hold down the power button.

#21 That sounds good, but I kind of hate to have to put it that way.  It's a Goldilocks problem: if you hold it too little it won't work, too long it screws you, you have to hold it down just right.

#22 No there is no way, my bad, the 8-second shutoff is not from the EC, it's pure hardware.

#22,23: The 8-second shutdown is a mix of EC firmware and hardware.

On most x86 systems, the PCH has a hard-coded circuit which shuts down if the power button is pressed for 4 seconds.  But we wanted 8 seconds, so we route that signal through the EC.  When the power button is pressed, the EC sends a short pulse on the line to the PCH, waits for 4 seconds, and then asserts the line.  That 4 second delay added to the 4 second hard-coded PCH delay makes 8 seconds.

This is implemented here: https://chromium.googlesource.com/chromiumos/platform/ec/+/master/common/power_button_x86.c

ARM systems implement the power-off delay in chipset-specific ways.  See for example:
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/power/rockchip.c

It's possible some ARM systems implement the 8 second delay in the PMIC; I didn't look through all of them.  That delay might not be configurable.

We didn't anticipate a need to have userspace cancel the power button off behavior, so there isn't an ectool command to do that.  Adding one would require an EC firmware update for all affected platforms.

The recommendation in #21 is correct.

Note that pretty much every computer (Windows, Mac, etc.) will respond with a clean shutdown on a brief power button press, and a hard unclean shutdown if you hold the button 4 seconds (due to the Intel PCH behavior).  Heck, even a Prius will hard-shutdown if you hold its power button long enough...

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

commit 5eb9c68c6eb649a0a349f93094204d34851294cd
Author: Eric Caruso <ejcaruso@chromium.org>
Date: Fri Mar 11 01:37:30 2016

power: Launch sync when the power button is pressed

Shutting down by holding the power button for a few seconds is
considered a supported way of turning off the system, and so should
not cause any filesystem issues. We may not be syncing early enough
in the shutdown process, so we should sync when the user first
presses the power button.

BUG= chromium:591078 
TEST=press power button, look for "Launching sync" in logs

Change-Id: Ifa142f947b57db016ef0ce7ff237b1a115d9f31e
Reviewed-on: https://chromium-review.googlesource.com/332231
Commit-Ready: Eric Caruso <ejcaruso@chromium.org>
Tested-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/5eb9c68c6eb649a0a349f93094204d34851294cd/power_manager/powerd/daemon.cc

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

commit 25500c8dae27a60dab062501ef7d829ed88c6257
Author: Eric Caruso <ejcaruso@chromium.org>
Date: Tue Mar 15 17:48:41 2016

power: Remove sync in HandleMissingPowerButtonAcknowledgment

Since we'll be syncing regardless of whether or not Chrome
acknowledges the power button press, we won't be using this
InputController::Delegate method for anything except logs.

BUG= chromium:591078 
TEST=unit tests

Change-Id: If6c3bba98fc262f8f4ad6221790557169cd3b595
Reviewed-on: https://chromium-review.googlesource.com/332446
Commit-Ready: Eric Caruso <ejcaruso@chromium.org>
Tested-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/25500c8dae27a60dab062501ef7d829ed88c6257/power_manager/powerd/daemon.cc

The sync invocation has moved up to when we press the power button.

Should we close this and file another bug for potentially adding the userspace EC cutoff cancellation?

@28, Sounds good although I think I'd lobby for EC cutoff time extension so things still default to shutdown if something goes wrong along the way.

I'll go take care of that.

Bulk verified