[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dead lock in repository
From: |
EricZolf |
Subject: |
Re: Dead lock in repository |
Date: |
Sat, 14 Jan 2023 07:32:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 |
Hi Robert,
were you able to reproduce the issue with the "persistent lock"?
Is Windows involved in this issue by chance? I had the issue during
early phases of my development, that stopped processes were still
recognized as running under Windows.
KR, Eric
On 02/01/2023 07:55, Eric Zolf wrote:
Hi,
On 02/01/2023 00:56, Robert Nichols wrote:
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.
Sorry, my bad, the lockfile is named indeed
`rdiff-backup-data/lock.yml`, but I still need more information to
repeat the issue.
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
Agreed, I'm also thinking about having a more fine-tunable approach
something like `--enforce unlock,somethingelse,etc`
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.
Locking is only done with API 201, so keeping 2.2.0 without
--api-version 201 should work as well for you.
API 201 isn't the default for a reason, so I encourage anybody to try
it, but API 200 is more tried and tested so far. API 201 will become the
default though in the next version and if nobody has tried it properly,
it will be of poor(er) quality.
KR, Eric