Lock never goes away

#1

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?

#2

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.

#3

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?

#4

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?

#5

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.