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

Restic panics on connection reset when backing up to S3 #560

Closed
lx7 opened this issue Aug 3, 2016 · 2 comments
Closed

Restic panics on connection reset when backing up to S3 #560

lx7 opened this issue Aug 3, 2016 · 2 comments

Comments

@lx7
Copy link

lx7 commented Aug 3, 2016

Output of restic version

restic 0.2.0 (v0.2.0-0-gc7f5ac2)
compiled at 2016-07-31 10:26:08 with go1.6.2

Expected behavior

Restic should be able to handle connection issues gracefully and retry. If after several retries the connection can not be re-established, restic should abort properly with a defined exit code.

Actual behavior

The restic process crashes with an unhandled panic() on disconnect.

scan [/srv/data/pictures]
scanned 21389 directories, 106521 files in 0:24
panic: Put https://my-bucket-name.s3-eu-west-1.amazonaws.com/restic/data/8b613a8128467e097483262eadaefd99a0763449cb09d0d367390cdf7ea69031: read tcp 192.168.178.2:24009->54.231.131.0:
443: read: connection reset by peer

goroutine 90776 [running]:
panic(0x9cb760, 0xc8234d0240)
        /usr/local/go/src/runtime/panic.go:481 +0x3e6
restic.(*Archiver).saveChunk(0xc821b26280, 0x1afa0b7, 0x2d2427, 0x512a07a100000, 0xc8400fc000, 0x2d2427, 0x4b6000, 0xc82387b600, 0x800e86520, 0xc8201487a8, ...)
        /tmp/restic-build-339571701/src/restic/archiver.go:165 +0x12b
created by restic.(*Archiver).SaveFile
        /tmp/restic-build-339571701/src/restic/archiver.go:237 +0x556

There's actually a TODO for this case at archiver.go:165

// TODO handle error
if err != nil {
    panic(err)
}

Steps to reproduce the behavior

Disconnect when backing up to S3.

@fd0
Copy link
Member

fd0 commented Aug 3, 2016

Hi, thank for creating an issue about this. It sounds similar to #415, although we've updated the minio-go library, which should handle reconnect to s3 internally.

To solve this problem, I'd like to implement a retry logic independently of the backend (see also #353).

@fd0
Copy link
Member

fd0 commented May 14, 2017

This should be solved with the latest update of the s3 connection library we're using. Please try again. Until then I'll close this report, we can always reopen it later.

@fd0 fd0 closed this as completed May 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants