runtime: "PowerRegisterSuspendResumeNotification failed with errno= 87" when running in Windows docker containers

[kzettlmeier]

What version of Go are you using (go version)?

$ go version
go version go1.13.6 windows/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=
set GOARCH=386
set GOBIN=
set GOCACHE=C:\Users\ContainerAdministrator\AppData\Local\go-build
set GOENV=C:\Users\ContainerAdministrator\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\gopath
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set GO386=sse2
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m32 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\ContainerAdministrator\AppData\Local\Temp\go-build649431418=/tmp/go-build -gno-record-gcc-switches

What did you do?

Trying to build an application for windows inside of a Windows docker container, using the following as the base image: golang:1.13.6-windowsservercore-1809

What did you expect to see?

I expected the build to be successful without a PowerRegisterSuspendResumeNotification failure

What did you see instead?

runtime: PowerRegisterSuspendResumeNotification failed with errno= 87
fatal error: runtime: PowerRegisterSuspendResumeNotification failure

runtime stack:
runtime.throw(0xe79862, 0x37)
	c:/go/src/runtime/panic.go:774 +0x79 fp=0x1d8fda8 sp=0x1d8fd78 pc=0x431789
runtime.monitorSuspendResume()
	c:/go/src/runtime/os_windows.go:307 +0x20a fp=0x1d8fe50 sp=0x1d8fda8 pc=0x42d8ea
runtime.goenvs()
	c:/go/src/runtime/os_windows.go:544 +0x1ba fp=0x1d8fea8 sp=0x1d8fe50 pc=0x42e26a
runtime.schedinit()
	c:/go/src/runtime/proc.go:554 +0xa9 fp=0x1d8ff00 sp=0x1d8fea8 pc=0x434189
runtime.rt0_go(0x1d8ff30, 0x7fffe2737974, 0x1d8ff30, 0x0, 0x7fffe2737974, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	c:/go/src/runtime/asm_amd64.s:214 +0x13d fp=0x1d8ff08 sp=0x1d8ff00 pc=0x45cf8d

[ianlancetaylor]

CC @aclements @alexbrainman @zx2c4

[ianlancetaylor]

Looks like error 87 is ERROR_INVALID_PARAMETERS, which doesn't make much sense to me.

[networkimprov]

Does Go tooling need to be aware of system-sleep? Maybe we need a switch to disable runtime.monitorSuspendResume().

[alexbrainman]

Looks like error 87 is ERROR_INVALID_PARAMETERS, which doesn't make much sense to me.

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?

Alex

PS: @ianlancetaylor I normally google for windows error numbers or something. And that search page brings some links to pages with all Windows errors. Once there, you can search the page by error number or name or even error message.

[gopherbot]

Change https://golang.org/cl/214917 mentions this issue: runtime: ignore power notification error seen on Windows Docker

[ianlancetaylor]

@gopherbot Please open backport issues. This same code was added to the 1.12 and 1.13 branches, and should be fixed there as well.

[gopherbot]

Backport issue(s) opened: #36574 (for 1.12), #36575 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[zx2c4]

Or maybe just ignore any errors returned from PowerRegisterSuspendResumeNotification, as @zx2c4 originally suggested. It does not feel right ignoring all errors on non-Docker.

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.

[gopherbot]

Change https://golang.org/cl/215002 mentions this issue: [release-branch.go1.13] runtime: ignore power notification error seen on Windows Docker

[gopherbot]

Change https://golang.org/cl/215017 mentions this issue: [release-branch.go1.12] runtime: ignore power notification error seen on Windows Docker

[alexbrainman]

... 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? ...

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.

https://stackoverflow.com/questions/43002803/detect-if-process-executes-inside-a-windows-container

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?

Alex

[gopherbot]

Change https://golang.org/cl/219657 mentions this issue: runtime: ignore error returned by PowerRegisterSuspendResumeNotification

[gopherbot]

Change https://golang.org/cl/224585 mentions this issue: [release-branch.go1.13] runtime: ignore error returned by PowerRegisterSuspendResumeNotification

[gopherbot]

Change https://golang.org/cl/224586 mentions this issue: [release-branch.go1.14] runtime: ignore error returned by PowerRegisterSuspendResumeNotification