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.

Sign up for GitHub

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

Jump to bottom

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

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

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

gopherbot opened this issue Jul 26, 2020 · 11 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone
Go1.14.9

Comments

@gopherbot
Copy link
Contributor

@alexbrainman requested issue #40167 to be considered for backport to the next 1.14 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 gopherbot added the CherryPickCandidate Used during the release process for point releases label Jul 26, 2020
@gopherbot gopherbot mentioned this issue Jul 26, 2020
Closed
@gopherbot gopherbot added this to the Go1.14.7 milestone Jul 26, 2020
@gopherbot
Copy link
Contributor Author

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

@gopherbot
Copy link
Contributor Author

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

@gopherbot
Copy link
Contributor Author

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

@zx2c4
Copy link
Contributor

zx2c4 commented Jul 27, 2020

Sorry for the churn. Please consult only https://golang.org/cl/244958

@alexbrainman
Copy link
Member

@dmitshur sorry to bother you, but we need this to be approved to be backported to go1.14. Can you help with that? If not, do you know who can approve it?

Thank you.

Alex

@dmitshur
Copy link
Contributor

dmitshur commented Aug 1, 2020

Thanks, we’ll try to take a look at this request next week.

For programs where it’s critical to receive stop / shutdown event, do you know if there is a workaround that can be used until this issue is resolved?

I’ve also asked a question on the upstream issue about 1.13 since that affects the 1.14 backport.

/cc @toothrot @cagedmangis @andybons

@alexbrainman
Copy link
Member

Thanks, we’ll try to take a look at this request next week.

Sounds good. Thank you.

For programs where it’s critical to receive stop / shutdown event, do you know if there is a workaround that can be used until this issue is resolved?

I don't know a workaround. Maybe others have good suggestions.

Alex

@toothrot toothrot modified the milestones: Go1.14.7, Go1.14.8 Aug 6, 2020
@alexbrainman
Copy link
Member

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

Thank you.

Alex

@dmitshur dmitshur mentioned this issue Aug 22, 2020
Closed
@dmitshur
Copy link
Contributor

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

@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Aug 22, 2020
@alexbrainman
Copy link
Member

The fix is at

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

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

Thank you.

Alex

@gopherbot
Copy link
Contributor Author

Closed by merging 7456a46 to release-branch.go1.14.

gopherbot pushed a commit that referenced this issue Aug 22, 2020
@zx2c4 @dmitshur
[release-branch.go1.14] runtime: detect services in signal handler
7456a46 
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 #40411.

Change-Id: Ia77871737a80e1e94f85b02d26af1fd2f646af96
Reviewed-on: https://go-review.googlesource.com/c/go/+/244958
Run-TryBot: Jason A. Donenfeld <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Alex Brainman <[email protected]>
@dmitshur dmitshur modified the milestones: Go1.14.8, Go1.14.9 Sep 1, 2020
@golang golang locked and limited conversation to collaborators Sep 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Projects
None yet
Milestone
Go1.14.9
Development

No branches or pull requests
5 participants
@toothrot @zx2c4 @dmitshur @gopherbot @alexbrainman