Should quit all processes in "apiserver-boot run local" when one of them failed.

[interma]

Problem:
Now if one process (etcd/apiserver/controller-manager) failed in apiserver-boot run local, other processes don't quit.
Then the following apiserver-boot run local will fail due to the existed processes.

e.g.

$ ./bin/apiserver-boot run local --generate=false
2018/07/19 12:57:03 CGO_ENABLED=0
go build -o bin/apiserver cmd/apiserver/main.go
go build -o bin/controller-manager cmd/controller-manager/main.go
etcd
bin/apiserver --etcd-servers=http://localhost:2379 --secure-port=9443 --delegated-auth=false
W0719 12:58:06.387862   83267 authorization.go:34] Authorization is disabled
W0719 12:58:06.387969   83267 authentication.go:56] Authentication is disabled
I0719 12:58:06.426003   83267 serve.go:89] Serving securely on [::]:9443
bin/controller-manager --kubeconfig=kubeconfig
to test the server run `kubectl --kubeconfig kubeconfig api-versions`
2018-07-19 12:58:08.179764 I | my controller is running
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x175fe7b]
...

# it's my code bug
# fixed code bug and run local again

$ ./bin/apiserver-boot run local --generate=false
2018/07/19 13:00:50 CGO_ENABLED=0
go build -o bin/apiserver cmd/apiserver/main.go
go build -o bin/controller-manager cmd/controller-manager/main.go
etcd
2018/07/19 13:01:48 Failed to run etcd exit status 1

Proposed Solution:
When failure happened, I think quit all processes is better. So users no needed to find and kill the existed processes manually.

Others:
Do you consider this as an improvement or bug fix? If so, I am very glad to open a PR to fix it.
Thanks.

[ghost]

This piece of code is quite fragile, yes. It doesn't handle interrupts well either and might leave processes running.

So +1 for improving that part.

[interma]

@damongant thanks for your reply.
My PR is here:
#255

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.