fix(windows): prevent infinite run. Fixes #11810 #11993
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
66e474a to
052c8b0
Compare
windows based workflows already call .Wait() in signal_windows.go, calling it twice will result in not exiting at all. Unix based workflows prevent that by releasing the process early on and checking exit code of all running processes. Windows workflows don't do this and without knowing in-depth how windows processes work, I didn't find a way to achieve a similar "wait for all processes" syscall. Signed-off-by: Michael Weibel <michael@helio.exchange>
052c8b0 to
21f3250
Compare
3 tasks
|
FYI this fix would need to go into 3.4.x and next release too. |
3 tasks
terrytangyuan
pushed a commit
that referenced
this pull request
Oct 19, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
windows based workflows already call .Wait() in signal_windows.go, calling it twice will result in not exiting at all.
Unix based workflows prevent that by releasing the process early on and checking exit code of all running processes.
Windows workflows don't do this and without knowing in-depth how windows processes work, I didn't find a way to achieve a similar "wait for all processes" syscall.
Fixes #11810
Motivation
The windows-only bug got introduced with PR #11368 but wasn't catched because seemingly windows tests aren't run automatically.
Modifications
simpleStartis now os specific code and does not attach a WaitDelay nor a Wait to the closer function.Verification
Ran the changed code locally and ran the windows emissary command tests locally which now run through again.