Re: Dead lock in repository

On 1/1/23 10:55 AM, EricZolf wrote:
> Hi Bob,
> 
> On 31/12/2022 18:45, Robert Nichols wrote:
>> OK, you've enhanced the locking of the repository. Lovely. How do I get rid of a dead lock? The process number mentioned in the error message does not exist on either the client or the server.
> 
> Can you be a bit more precise what your problem exactly is?
> 
> 1. rdiff-backup should refuse to work only if the PID stored corresponds to an existing process (it was an enhancement added based on Patrik's feedback).
> 2. The .lock file remains even after the first backup with API 201, so that it can be used to lock the repo even without write access rights (e.g. for restore/list activities).
> 3. as last resort, the `--force` flag should ignore any lock (at your own risk though).

I got a message that another rdiff-backup process with PID xxxx was running in that archive, coupled with a warning that running two rdiff-backup processes simultaneously could result in severe corruption of the archive. rdiff-backup then suggested that running with "--force" would bypass the restriction, and exited with an error status. As I said, that PID did not exist on either the client or the server. In fact, there was no other rdiff-backup process running anywhere on my network. I looked for a possible ".lock" file and did not find any. There was an empty "lock.xxx" (I forget what "xxx" was), which I tried removing, to no avail.

I'm paraphrasing since I don't have the original message, and my workaround was to rsync the entire archive from a stored copy.

Unfortunately, "--force" is a bit too heavy a hammer to be wielding for this situation, as it would also override other conditions that I wanted to respect. I'm locking that server to rdiff-backup-2.0.5 since that seems to be the last working version for me.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.