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

snapshot save command does not timeout #10298

Closed
jingyih opened this issue Dec 5, 2018 · 4 comments
Closed

snapshot save command does not timeout #10298

jingyih opened this issue Dec 5, 2018 · 4 comments

Comments

@jingyih
Copy link
Contributor

jingyih commented Dec 5, 2018

Currently etcdctl snapshot save does not timeout. It could hang indefinitely. Besides, if user specifies command timeout in flag --command-timeout, the command will not use this timeout.

if err := sp.Save(context.TODO(), *cfg, path); err != nil {
ExitWithError(ExitInterrupted, err)
}

One possible solution is to route --command-timeout to snapshot save command. But the default timeout is only 5 seconds. This might cause more issues to users if they do not specify timeout when calling snapshot save.

defaultCommandTimeOut = 5 * time.Second

Any ideas on how to resolve this?

/cc @jpbetz @gyuho @xiang90

@gyuho
Copy link
Contributor

gyuho commented Dec 5, 2018

Sure, we can set the context timeout?

// Snapshot provides a reader for a point-in-time snapshot of etcd.
// If the context "ctx" is canceled or timed out, reading from returned
// "io.ReadCloser" would error out (e.g. context.Canceled, context.DeadlineExceeded).
Snapshot(ctx context.Context) (io.ReadCloser, error)

@xiang90
Copy link
Contributor

xiang90 commented Dec 5, 2018

@jingyih Probably set a different default timeout (keep current infinity or something like 10minutes ) for snapshot command. When users specify the command timeout explicitly, overwrite it.

@jpbetz
Copy link
Contributor

jpbetz commented Dec 5, 2018

Ah, maybe just document that the timeout is different for the snapshot operation and implement it in code to be special cased? I'm in favor of having the default be "no timeout", mostly for backward compatibility. We should probably apply the same treatment to the recover operation as well.

@jingyih
Copy link
Contributor Author

jingyih commented Dec 5, 2018

Thanks for all the inputs:) I think we agreed on what the behavior should be. I'll send a fix.

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

No branches or pull requests

4 participants