Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: "PowerRegisterSuspendResumeNotification failed with errno= 87" when running in Windows docker containers #36557
What version of Go are you using (
I think this errors means - this code is not supported on Docker - in this context. There are only so many Windows error messages available, so, as a programmer, you have to pick best exiting number that fits.
And ERROR_INVALID_PARAMETERS fits much better than ERROR_FILE_NOT_FOUND. We are looking for ERROR_FILE_NOT_FOUND returned from PowerRegisterSuspendResumeNotification at this moment to detect Docker environment.
I think we should add ERROR_INVALID_PARAMETERS to the list of errors we are looking for there.
Or maybe just ignore any errors returned from PowerRegisterSuspendResumeNotification, as @zx2c4 originally suggested. It does not feel right ignoring all errors on non-Docker.
Unrelated, but maybe we should run one of our builders in Windows Docker container. I believe, Windows Docker containers are available on GCP. Maybe having Docker builder will pick errors like this. @bradfitz what do you think?
PS: @ianlancetaylor I normally google for
I still sort of think this is best. If we fail silently for some bad reason, how bad is it actually? And if the power notifier is borked, how much else from the power stack is borked? We can roll with this and see if we get additional reports at some point, I guess, but if this becomes a frequent thing, it doesn't seem like that bad of an assumption that power management notifier failures are always related to the kernel not advancing the clock anyway for WaitFor*Object and such.
… on Windows Docker Updates #36557 Fixes #36575 Change-Id: Ia8125f382d5e14e5612da811268a58971cc9ac08 Reviewed-on: https://go-review.googlesource.com/c/go/+/214917 Run-TryBot: Ian Lance Taylor <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Brad Fitzpatrick <email@example.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Austin Clements <firstname.lastname@example.org> (cherry picked from commit d2de9bd) Reviewed-on: https://go-review.googlesource.com/c/go/+/215002
… on Windows Docker Updates #36557 Fixes #36574 Change-Id: Ia8125f382d5e14e5612da811268a58971cc9ac08 Reviewed-on: https://go-review.googlesource.com/c/go/+/214917 Run-TryBot: Ian Lance Taylor <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Brad Fitzpatrick <email@example.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Austin Clements <firstname.lastname@example.org> (cherry picked from commit d2de9bd) Reviewed-on: https://go-review.googlesource.com/c/go/+/215017
You assume that if PowerRegisterSuspendResumeNotification returns error than Windows power stack is broken. But I am not convinced that this is true. It seems that way on Docker, but we haven't had any reports of PowerRegisterSuspendResumeNotification error on non Docker. So it seems to be working fine on non Docker, and we should care about any PowerRegisterSuspendResumeNotification failure on Windows.
And things might change in time. For example, Microsoft might decide to implement PowerRegisterSuspendResumeNotification in Docker.
Also maybe we could somehow determine, if we running inside Docker, and only ignore errors, if in Docker.
And I was under impression that you cared about Windows programs clocks, because of WireGuard. How can you be certain about clocks, if you ignore PowerRegisterSuspendResumeNotification errors? You know it is broken in Docker. But you still want to be sure about your Windows clients. Aren't you?