-
- VP, Product Management
- Posts: 6033
- Liked: 2859 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Issues After 4.1.2 Upgrade
OK, so I upgraded to 4.1.2 today to hopefully fix the issue with Veeam keeping sessions open to Windows 7 hosts but now I've got a new issues. All of my backups are now failing with messages like the following:
Checking backup version Failed to wait mutex perlsoap zso-artemis.zeusinc.com: timeout 20 sec exceeded
We're backing up to a Linux target (as we always have). I'll open a support case but just wondering if this has been seen before by anyone.
Checking backup version Failed to wait mutex perlsoap zso-artemis.zeusinc.com: timeout 20 sec exceeded
We're backing up to a Linux target (as we always have). I'll open a support case but just wondering if this has been seen before by anyone.
-
- VP, Product Management
- Posts: 27357
- Liked: 2788 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Issues After 4.1.2 Upgrade
Tom,
I've seen this error while working in support. This issue may be related either to an existing overlap between the jobs, or to a heavy load on the target host (in your case the Linux server), which is preventing us from installing the agent in a given time.
If you are keep getting this issue, I recommend working with our support directly for quicker resolution.
I've seen this error while working in support. This issue may be related either to an existing overlap between the jobs, or to a heavy load on the target host (in your case the Linux server), which is preventing us from installing the agent in a given time.
If you are keep getting this issue, I recommend working with our support directly for quicker resolution.
-
- Chief Product Officer
- Posts: 31768
- Liked: 7271 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Issues After 4.1.2 Upgrade
Hi Tom, no we definitely have not seen this reported for the past month - so far the feedback on 4.1.2 was that the upgrade is flawless for everyone. What is your support case number?
-
- VP, Product Management
- Posts: 6033
- Liked: 2859 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Issues After 4.1.2 Upgrade
Actually, I was going to open a support case, but I decided to take a look at the Linux server before doing so because backup jobs were only failing to this one Linux target (jobs that point to other Linux targets seemed to be working fine). There was nothing obviously wrong with the host, but there were 3 or 4 SSH sessions with Veeam child processes that looked to be, for lack of a better word, "stuck". They were obviously Veeam processes as the looked something like this:
13548 ? Ss 0:01 sshd: root@notty
13598 ? Ss 0:00 bash -c (cd /tmp && perl veeam_soapf9e41134-1646-4cb4-8080-4bf77f6096a0.pl -d -c -l libf9e411
34-1646-4cb4-8080-4bf77f6096a0 -e /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>> /tmp/veeam_errorf9e41134-1646
-4cb4-8080-4bf77f6096a0) || cat /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>&1
13611 ? S 0:00 bash -c (cd /tmp && perl veeam_soapf9e41134-1646-4cb4-8080-4bf77f6096a0.pl -d -c -l libf9e411
34-1646-4cb4-8080-4bf77f6096a0 -e /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>> /tmp/veeam_errorf9e41134-1646
-4cb4-8080-4bf77f6096a0) || cat /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>&1
13612 ? S 0:00 perl veeam_soapf9e41134-1646-4cb4-8080-4bf77f6096a0.pl -d -c -l libf9e41134-1646-4cb4-8080-4b
f77f6096a0 -e /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0
Two of the processes had started around the time of the nightly jobs, but one of them had been around for over a week and appeared to simply be an orphan. I made sure all jobs pointing to that target were stopped and then killed off all of these orphaned processes. Restarted the jobs, and all is good again. It almost looked like at some point in the past a job failed, but left it's process open on the Linux target but for some reason this orphaned process didn't cause any problem until after the 4.1.2 upgrade.
Anyway, after manually killing/cleaning up all the processes on the Linux host everything works great again so we're good to go.
13548 ? Ss 0:01 sshd: root@notty
13598 ? Ss 0:00 bash -c (cd /tmp && perl veeam_soapf9e41134-1646-4cb4-8080-4bf77f6096a0.pl -d -c -l libf9e411
34-1646-4cb4-8080-4bf77f6096a0 -e /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>> /tmp/veeam_errorf9e41134-1646
-4cb4-8080-4bf77f6096a0) || cat /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>&1
13611 ? S 0:00 bash -c (cd /tmp && perl veeam_soapf9e41134-1646-4cb4-8080-4bf77f6096a0.pl -d -c -l libf9e411
34-1646-4cb4-8080-4bf77f6096a0 -e /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>> /tmp/veeam_errorf9e41134-1646
-4cb4-8080-4bf77f6096a0) || cat /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0 2>&1
13612 ? S 0:00 perl veeam_soapf9e41134-1646-4cb4-8080-4bf77f6096a0.pl -d -c -l libf9e41134-1646-4cb4-8080-4b
f77f6096a0 -e /tmp/veeam_errorf9e41134-1646-4cb4-8080-4bf77f6096a0
Two of the processes had started around the time of the nightly jobs, but one of them had been around for over a week and appeared to simply be an orphan. I made sure all jobs pointing to that target were stopped and then killed off all of these orphaned processes. Restarted the jobs, and all is good again. It almost looked like at some point in the past a job failed, but left it's process open on the Linux target but for some reason this orphaned process didn't cause any problem until after the 4.1.2 upgrade.
Anyway, after manually killing/cleaning up all the processes on the Linux host everything works great again so we're good to go.
-
- Chief Product Officer
- Posts: 31768
- Liked: 7271 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Issues After 4.1.2 Upgrade
Great, thanks for the update.
-
- Novice
- Posts: 5
- Liked: never
- Joined: Sep 06, 2013 5:55 am
- Full Name: René Schärer
- Contact:
Re: Issues After 4.1.2 Upgrade
Hi tsighter
(I'm not a Linux Crack, we use it only as a Repository)
Is it possible to get more Information about what you did (in detail) on the Linux to find and kill the orphaned processes.
We have such a issue in v7. At the Moment the only solution in our case is to reboot the Backup Server (not the Linux repository).
regards
René
(I'm not a Linux Crack, we use it only as a Repository)
Is it possible to get more Information about what you did (in detail) on the Linux to find and kill the orphaned processes.
We have such a issue in v7. At the Moment the only solution in our case is to reboot the Backup Server (not the Linux repository).
regards
René
-
- Product Manager
- Posts: 20382
- Liked: 2292 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Issues After 4.1.2 Upgrade
I'm not a Linux expert, but I think you can use ps aux along with u switch to list all processes along with their owners. And then issue kill command to the process with corresponding PID. Thanks.
Who is online
Users browsing this forum: Bing [Bot], Gostev, renatorichina, Semrush [Bot], tkado and 114 guests