-
Notifications
You must be signed in to change notification settings - Fork 235
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
Quit all processes when "apiserver-boot run local" failed #255
Conversation
I can't review this, but I'd suggest you do the following:
func cancelWhenSignaled(parent context.Context) context.Context {
ctx, cancel := context.WithCancel(parent)
go func() {
signalChannel := make(chan os.Signal)
signal.Notify(signalChannel, os.Interrupt, os.Kill)
<-signalChannel
cancel()
}()
return ctx
} |
Thanks @damongant |
@damongant Thanks for your help. |
cmd/apiserver-boot/boot/run/local.go
Outdated
log.Printf("Failed to run controller-manager %v", err) | ||
stopCh <- struct{}{} | ||
log.Printf("Failed to run %s, error: %v\n", cmdName, err) | ||
stopCh <- err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can save this line and the else and just stopCh<-err
- it'll be nil in the else case either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I will update this.
cmd/apiserver-boot/boot/run/local.go
Outdated
cancel() | ||
case <-ctx.Done(): | ||
// other commands quited | ||
cmd.Process.Kill() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to check if cmd.Process
is nil
here? Unfortunate timing with 2 processes exiting could produce a segfault here afaik, but I'm not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, check nil is better, I will update them later.
LGTM overall, didn't have a chance to test yet. |
@pwittrock Could you help to review this? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
I'd hate for this contribution to go to waste because of inactive maintainers. wink wink nudge nudge /remove-lifecycle stale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apologies for delayed response, i'm having trouble finding out active threads in the pool 🧐
@@ -139,3 +142,16 @@ func CheckInstall() { | |||
strings.Join(missing, ",")) | |||
} | |||
} | |||
|
|||
func CancelWhenSignaled(parent context.Context) context.Context { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reusing existing signal handler from here seems better to me :
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@interma any plan to bump the thread?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double-receiving should be a fine addition to this piece of code if that's what you mean, but the context is also used to support cancelling when one of the processes unexpectedly quits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double-receiving should be a fine addition to this piece of code if that's what you mean
for now we're not catching signal in the code so there's no double-receiving. i mean the pull LGTM overall, but we should reuse the existing code from upstream as much as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've attempted to address this final code-review comment in #410
It'd be great to get this fixed in the next release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trouble is that importing SetupSignalHandler from k8s.io/apiserver causes a clash with the k8s.io/kube-openapi dependency.
So I copied the code across instead.
I remember apiserver-builder is deprecated last year, reloads now? |
for now, we don't see a better replacement tooling/SDK for AA server so we're still delivering it. actually there were supposed to be a replacement for AA-builder, we planed and named it
generally, we're aiming at converging this project w/ kubebuilder (which is now actively maintained by phil and his team) to share the same framework like |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@wallrj Ok, no problem, thanks! |
Fix:
#253
Glad to open my first PR, thanks for your review.