Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: Windows service lifecycle events behave incorrectly when called within a golang environment [1.15 backport] #40412

Closed
gopherbot opened this issue Jul 26, 2020 · 6 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 26, 2020

@alexbrainman requested issue #40167 to be considered for backport to the next 1.15 minor release.

I think the CL (242280) is safe,

Thank you for checking, @ianlancetaylor

but I don't know how important it is to land at this late stage of the release cycle. I gave the CL a +1 and I'll let Alex decide whether to put it in for 1.15.

I think CL 242280 is important enough so it is available to Go 1.14 and 1.15 users, but is not important enough so it delays imminent Go 1.15 release. So, I propose, we merge CL 242280 on release-branch.go1.14 and release-branch.go1.15 (once Go 1.15 is released) branches. And submit CL 243597 on master once Go 1.15 is released.

@gopherbot, please backport to Go 1.14 and Go 1.15. This is serious problem where Windows service does not receives stop / shutdown event.

@zx2c4 would you, please, copy CL 242280 onto release-branch.go1.14, so we can have it available as soon as possible. Or I can do it myself, if you like.

Thank you.

Alex

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Jul 27, 2020

Change https://golang.org/cl/244959 mentions this issue: [release-branch.go1.15] runtime: detect services in signal handler

@andybons andybons modified the milestones: Go1.15, Go1.15.1 Aug 6, 2020
@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Aug 22, 2020

Pinging @dmitshur - we would like the approval of this change to be back-ported.

Thank you.

Alex

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Aug 22, 2020

Approved per discussion in a release meeting. This is fixing a serious issue without a workaround. This backport applies to both 1.15 (this issue) and 1.14 (#40411).

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Aug 22, 2020

The fix is at

https://go-review.googlesource.com/c/go/+/244959/

and gave it +2. How do we get it submitted (my submit button is disabled)?

Thank you.

Alex

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Aug 22, 2020

How do we get it submitted (my submit button is disabled)?

From https://golang.org/wiki/MinorReleases#making-cherry-pick-cls:

Gerrit is configured to only allow release managers to submit to release branches, but the code review process is otherwise the usual.

I'll take care of it now.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Aug 22, 2020

Closed by merging b1253d2 to release-branch.go1.15.

@gopherbot gopherbot closed this Aug 22, 2020
gopherbot pushed a commit that referenced this issue Aug 22, 2020
The service handler needs to handle CTRL+C-like events -- including
those sent by the service manager itself -- using the default Windows
implementation if no signal handler from Go is already listening to
those events. Ordinarily, the signal handler would call exit(2), but we
actually need to allow this to be passed onward to the service handler.
So, we detect if we're in a service and skip calling exit(2) in that
case, just like we do for shared libraries.

Updates #40167.
Updates #40074.
Fixes #40412.

Change-Id: Ia77871737a80e1e94f85b02d26af1fd2f646af96
Reviewed-on: https://go-review.googlesource.com/c/go/+/244959
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
@dmitshur dmitshur modified the milestones: Go1.15.1, Go1.15.2 Sep 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants