Re: Dead lock in repository

[Robert Nichols]

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.