service on docker with Ctrl-C: error stopping tunnel: stopping ssh tunnel: os: process already finished

[tstromberg]

This is a useless and necessarily scary error message from minikube service when Ctrl-C is hit on macOS and the Docker driver:

🎉  Opening service triage-party/triage-party in default browser...
❗  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
^C✋  Stopping tunnel for service triage-party.

💣  error stopping tunnel: stopping ssh tunnel: os: process already finished

😿  minikube is exiting due to an error. If the above message is not useful, open an issue:
👉  https://github.com/kubernetes/minikube/issues/new/choose

[vinu2003]

@tstromberg & @medyagh - I am new to this community and looking to learn and contribute. Can I pick this up ? and start experiment if no one else is looking into it.
Thanks!

[tstromberg]

Absolutely! You are more than welcome to pick this up. Thanks!

…

On Thu, Jun 18, 2020 at 7:45 PM Vinodhini Balusamy ***@***.***> wrote: @tstromberg <https://github.com/tstromberg> & @medyagh <https://github.com/medyagh> - I am new to this community and looking to learn and contribute. Can I pick this up ? and start experiment if no one else is looking into it. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8511 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYYMB5SGMWSYAQW765EODRXLGLBANCNFSM4OB54BTQ> .

[vinu2003]

/assign @vinu2003

[vinu2003]

@tstromberg I have verified this issue in my local macOS setup with docker.
The reason that we get this error is the ssh service tunnel process termination doesn't return 'nil' when the process is-done successfully waited on. The error handling is done here and exit with error.

But the error that is returned from os.signal function in go seems to be private:
(for 2 cases isDone and ERSCH as well)
go/src/os/exec_unix.go

var errFinished = errors.New("os: process already finished")

func (p *Process) signal(sig Signal) error {
	if p.Pid == -1 {
		return errors.New("os: process already released")
	}
	if p.Pid == 0 {
		return errors.New("os: process not initialized")
	}
	p.sigMu.RLock()
	defer p.sigMu.RUnlock()
	if p.done() {
		return errFinished
	}
	s, ok := sig.(syscall.Signal)
	if !ok {
		return errors.New("os: unsupported signal type")
	}
	if e := syscall.Kill(p.Pid, s); e != nil {
		if e == syscall.ESRCH {
			return errFinished
		}
		return e
	}
	return nil
}

And there is discussion/proposal to export errFinished to ErrFinished.
Please note: golang/go#39444

All your concern is about these below lines when SIGINT is sent from.
💣 error stopping tunnel: stopping ssh tunnel: os: process already finished

😿 minikube is exiting due to an error. If the above message is not useful, open an issue:
👉 https://github.com/kubernetes/minikube/issues/new/choose

I suggest we can get this in place and handle the specific error case here and exit gracefully in minikube/cmd/service.go if it's the proposal is approved.

Keen to know your thoughts on this.

[vinu2003]

Proposal to export errFinished - golang/go#39444 seems to be OK. Its in final comment period.

[vinu2003]

https://go-review.googlesource.com/c/go/+/242998/ - proposal accepted. Once its in we can update and get similar issues error handling addressed correctly.

[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

[ilya-zuyev]

@vinu2003 are you still interested in fixing this issue?

[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-contributor-experience at kubernetes/community.
/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-contributor-experience at kubernetes/community.
/lifecycle rotten

[vishjain]

/assign

[sharifelgamal]

Please reach out if you have any questions working on this issue.

[igbanam]

I just experienced this issue while going through the Example: Deploying WordPress and MySQL with Persistent Volumes. I know neither Go nor Kubernetes, but I am interested in the latter. So I'm interested in the solution here. I can help test where necessary

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten