This post is more than 5 years old
1 Rookie
•
89 Posts
0
3402
December 16th, 2016 08:00
Avamar replication error "Failed to acquire client lock"
I'm going to open up an SR, but in the meantime was wondering if anyone has run into this. I have a number of clients that don't replicate for some reason when the normal replication job runs, I can't figure out why. When I try to do a forced Replicate on these clients that doesn't replicate I get the error below"
avrepl Error <42085>: Failed to acquire replication client lock: (/usr/local/avamar/var/client/.replicate-#my.vcenter.com/domain/domain/clientname....... code 36 File name too long
Anybody run into this before? I only see this when I do a forced replicate on a single client, during a scheduled replication I don't get any errors it just doesn't attempt to replicate those clients at all, like it skips right over them.
Avamar Exorcist
462 Posts
0
March 20th, 2017 03:00
Hi Daryn , I’m pleased to hear that you managed to find a workaround for the issue - thanks for sharing it.
I reviewed our SR database and found that for another customer this behaviour occurred because their VM path (Avamar domain path + client hostname) was too long. This might be why the TSE you worked with suggested to shorten the name of the client.
I identified and reviewed your SR (xxxx1704). Since it was abandoned it wasn't possible for Support to obtain sufficient information identify the root cause of the issue or to consult with Engineering but, if you are still able to reproduce this behaviour and you’d still like to investigate why it occurs when replication is configured with “Replicate client backups in parallel”, please don’t hesitate to open another SR and quote this thread along with your original SR number.
Additionally, a 'skeleton' knowledge article 497557 has been created to document this issue. If we work with another customer who encounters the same error we can subsequently populate that with information on root cause and how to resolve it.
All the best,
Nick
garysperano
4 Posts
0
March 16th, 2017 12:00
Did you ever open a support case? If so, what was you case number? I am running into the same issue
Clarkson14
1 Rookie
•
89 Posts
1
March 16th, 2017 15:00
Just to start, which I didn't mention in the original post, because i didn't know at the time, was my problems were happening when I had replication set with the "Replicate client backups in parallel". What I found out was replication worked fine for me when I switched it to "Default Mode", though that was not something the SR tech helped deduce ...
Because the SR I did end up opening turned out to be a waste of time IMO, the tech told me I should rename my VMs that weren't replicating to shorter names, presumably because of the "File name too long" error, I had VMs with longer names working fine but he just kept coming back to renaming VMs which was a stupid conclusion IMO, and not an option as it was 150+ VMs we were talking about.
I ended up switching it to "Default Mode" myself, figured back to the basics, and oddly the next morning all clients were replicating and back filling missed jobs and missed clients. I was headed out for the holidays and just let it be. I've left it that way since, my replication jobs finish in a 3-4 hours windows so I just haven't messed with it.
I mentioned it to another tech I was talking to on another call on another unrelated replication issue and he was kind of under the same thought, if I was fine with replication times and not having issues in Default Mode to just let it be. So that's where I kept it.
This has most likely been no help so apologize for the long read, but unfortunately I never did get an actual explanation for the original errors that could be of some help, I got it working and have kept it in the "If it ain't broke..." mode. If you do open an SR, I just hope you don't end up with the same tech I did.