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.

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

fix: report timeout as error instead of writing message to stderr #68

Merged
merged 4 commits into from
Dec 9, 2021

Conversation

AstroProfundis
Copy link
Contributor

@AstroProfundis AstroProfundis commented Jun 8, 2021

I have observed panics on some specific commands:

panic: send on closed channel

goroutine 2017 [running]:
github.com/appleboy/easyssh-proxy.(*MakeConfig).Stream.func1(0xc0000ca0a0, 0xc00013e090, 0xc000fea168, 0x1, 0x1, 0xc000de4b80, 0xc000de4c00, 0xc000690ea0, 0xc000690f00, 0xc000690f60, ...)
	/home/allen/go/pkg/mod/github.com/appleboy/[email protected]/easyssh.go:340 +0x385
created by github.com/appleboy/easyssh-proxy.(*MakeConfig).Stream
	/home/allen/go/pkg/mod/github.com/appleboy/[email protected]/easyssh.go:297 +0x4a5

That the stderrChan is closed before timeout message is written to it. However, if closing the channel in the upper level goroutine, it's possible that stderrScanner continues to read data after timeout reached, if the channel is closed in timeout case, it still panics.

So use the errChan to report timeout and let stderrChan purely be with the stderr of command output, to avoid writing and closing the channel in two different goroutines.

@codecov-commenter
Copy link

codecov-commenter commented Jun 8, 2021

Codecov Report

Merging #68 (d52fc63) into master (e954c88) will decrease coverage by 0.07%.
The diff coverage is 100.00%.

❗ Current head d52fc63 differs from pull request most recent head 9910ebd. Consider uploading reports for the commit 9910ebd to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master      #68      +/-   ##
==========================================
- Coverage   83.55%   83.48%   -0.08%     
==========================================
  Files           1        1              
  Lines         225      224       -1     
==========================================
- Hits          188      187       -1     
  Misses         21       21              
  Partials       16       16              
Impacted Files Coverage Δ
easyssh.go 83.48% <100.00%> (-0.08%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e954c88...9910ebd. Read the comment docs.

@AstroProfundis
Copy link
Contributor Author

@amyangfei PTAL too, as this was introduced in #66

@AstroProfundis AstroProfundis changed the title fix: close stderrChan out of child goroutine fix: report timeout as error instead of writing message to stderr Jun 11, 2021
@AstroProfundis AstroProfundis force-pushed the stderrchan branch 2 times, most recently from 1029d75 to bfa1be1 Compare June 15, 2021 04:39
@gzuidhof
Copy link

I may be wrong, but I'm pretty sure the isTimeout variable is wrong and inverted in this library, this is the relevant bit of code. Maybe it's related?

@appleboy appleboy merged commit 6671f69 into appleboy:master Dec 9, 2021
@AstroProfundis AstroProfundis deleted the stderrchan branch February 9, 2022 06:44
@realcp1018
Copy link

easyssh-proxy/easyssh.go

Lines 336 to 342 in 6671f69

case <-res:
errChan <- session.Wait()
doneChan <- true
case <-timeoutChan:
errChan <- fmt.Errorf("Run Command Timeout")
doneChan <- false
}

Write false to doneChan is enougth when timeout, no need to send error msg to errChan.

@realcp1018
Copy link

realcp1018 commented Aug 1, 2022

I may be wrong, but I'm pretty sure the isTimeout variable is wrong and inverted in this library, this is the relevant bit of code. Maybe it's related?

Rename isTimeout to isDone seems better in Run() loop?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants