fix restic unlock success detection

[Gardelll]

Summary

• rely on restic unlock exit status instead of matching success in stdout
• log restic unlock output when present
• avoid false unlock failures in scheduled restic backups

Context

In a docker-mc-backup container using BACKUP_METHOD=restic with an S3-compatible RESTIC_REPOSITORY, the scheduled backup path repeatedly logged:

INFO Repository already initialized
INFO Checking for stale locks
WARN Confirmed stale lock on repo, unlocking...
ERROR Unable to unlock the repo. Is there another process running?

However, in the same container:

• backup now succeeded
• restic list locks returned no output and exited 0 immediately after the scheduled failure
• restic unlock -v returned no output and exited 0 immediately after the scheduled failure

The existing logic requires restic unlock stdout to contain success, which can misclassify a successful unlock when the command exits 0 without printing that string.

[Gardelll]

Quick test update from my side.

I built this branch into a custom image and rolled it out to a test docker-mc-backup sidecar using BACKUP_METHOD=restic with an S3-compatible RESTIC_REPOSITORY.

What I checked in the test container:

• the patched /opt/backup-loop.sh is present
• backup now works
• the cron-equivalent path also works when run as:
  • export ONE_SHOT=true; /opt/backup-loop.sh

That cron-equivalent run went through:

• Repository already initialized
• Checking for stale locks
• Checking repo integrity
• backup completed successfully
• a new snapshot was saved
• prune completed successfully

In this test run I did not hit the previous pattern:

WARN Confirmed stale lock on repo, unlocking...
ERROR Unable to unlock the repo. Is there another process running?

[itzg]

Thanks! Ready for me to merge this?

[Gardelll]

Thanks! Ready for me to merge this?

Yes, that works fine for me.