Output of restic version
restic 0.18.0 compiled with go1.24.4 on linux/amd64 (on latest Fedora, F42, using the packaged version)
What backend/service did you use to store the repository?
Repo on hard drives / local drive
Problem description / Steps to reproduce
I first noted the issue relatively recently when backing up onto external hard drives (LUKS + btrfs RAID1 volume). My normal run would be to do a dry-run first and then backup. After the dry run, restic hangs when attempting to re open the repo. The same hangs happen with other commands, such as check or forget. I would say that it hangs about 1 in 2 to 1 in 4 times.
I've tried to reproduce the issue on a blank setup with the following:
restic init -r testrepo
restic check -r testrepo
using temporary cache in /tmp/restic-check-cache-2953796536
create exclusive lock for repository
enter password for repository:
# prompt shows, so cancel with ^C
signal interrupt received, cleaning up
context canceled
# keep doing this until it hangs
using temporary cache in /tmp/restic-check-cache-2645346029
create exclusive lock for repository
... (hangs indefinitely)
On an empty test repo, this hangs perhaps 1 in 50 times. Thinking that perhaps the amount of snapshots on my backup drives matter, I ran forget to get from ~180 snapshots to ~40 and it did decrease the frequency of the hangs - which could also explain that it takes a significant number of attempts on a blank repo to hang it.
Expected behavior
Always able to open the repo
Actual behavior
Need to cancel with ^C before attempting to open again the repo
Do you have any idea what may have caused this?
I did not notice it on the 0.17.X branch. After further testing, that may be linked to the password request routine? Using a dummy repo and doing: RESTIC_PASSWORD=test restic check -r testrepo does not seem to hang it. And actually entering the password before attempting the same command seems to hang more often than just using ^C and repeating the command.
Did restic help you today? Did it make you happy in any way?
Yes, restic is a WONDERFUL piece of software. I've been backing up on hard drives, and online first through the s3 dedicated interface and then using rclone (another amazing piece of software) for years. I've only ever had one issue (the storage provider messed up a blob) and could recover from it. Thank you so much!
Output of
restic versionrestic 0.18.0 compiled with go1.24.4 on linux/amd64(on latest Fedora, F42, using the packaged version)What backend/service did you use to store the repository?
Repo on hard drives / local drive
Problem description / Steps to reproduce
I first noted the issue relatively recently when backing up onto external hard drives (LUKS + btrfs RAID1 volume). My normal run would be to do a dry-run first and then backup. After the dry run, restic hangs when attempting to re open the repo. The same hangs happen with other commands, such as
checkorforget. I would say that it hangs about 1 in 2 to 1 in 4 times.I've tried to reproduce the issue on a blank setup with the following:
On an empty test repo, this hangs perhaps 1 in 50 times. Thinking that perhaps the amount of snapshots on my backup drives matter, I ran
forgetto get from ~180 snapshots to ~40 and it did decrease the frequency of the hangs - which could also explain that it takes a significant number of attempts on a blank repo to hang it.Expected behavior
Always able to open the repo
Actual behavior
Need to cancel with ^C before attempting to open again the repo
Do you have any idea what may have caused this?
I did not notice it on the 0.17.X branch. After further testing, that may be linked to the password request routine? Using a dummy repo and doing:
RESTIC_PASSWORD=test restic check -r testrepodoes not seem to hang it. And actually entering the password before attempting the same command seems to hang more often than just using ^C and repeating the command.Did restic help you today? Did it make you happy in any way?
Yes, restic is a WONDERFUL piece of software. I've been backing up on hard drives, and online first through the
s3dedicated interface and then usingrclone(another amazing piece of software) for years. I've only ever had one issue (the storage provider messed up a blob) and could recover from it. Thank you so much!