Lock never goes away


I have systemd doing a daily backup & forget, plus a monthly prune, to a B2 bucket.

I see messages about old locks, like this:
Fatal: unable to create lock in backend: repository is already locked exclusively by PID 22258 on localhost.localdomain by lance (UID 1000, GID 1000)
lock was created at 2019-05-01 00:00:26 (10h56m15.487366228s ago)
storage ID 4ad352c2

I don’t know why I’d have a lock that’s11 hours old; when I’m only doing incremental backups on a desktop. Do we have detailed documentation on how to automatically deal with locks, making sure things happen if they get bumped by a lock, etc., so we can get to an end-user experience that’s set-it-and-forget-it easy?


I had a problem that a cron based restic backup did not work anymore for some days because there was also an “orphaned” lock. I just noticed it by chance.

Not sure how to avoid this. I was thinking about doing an restic unlock via cron one time a week - just to be sure.


I’m still working on this, it seems to be a critical problem: My daily systemd timer runs once, then never runs again! Forcibly removing locks before each daily backup is a bad work-around since it might break other things…like a pruning job that could be running concurrently, on a less frequent timer.

Any idea if this is more likely a Restic problem or a B2 problem?


I had this problem only once with a sftp backend. Still I ask myself what could be a solution. Backends can go down during backup. In my case it may was maintenance work on the backend server. Such things happen - and the lock remains while I feel safe having my daily cronjob that can’t run.

In your case I don’t think it’s a restic problem. Does the same problem occure when you run the backup manually?


Check that your B2 key has permission to delete files.

Also, consider having cronjob output emailed to you or a sysadmin mailing list, and also run restic backup with -q. This way the only output will be related to errors, and then you’ll get an email when something goes wrong.