Issues After 4.1.2 Upgrade

[tsightler]

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.

[Vitaliy S.]

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.

[Gostev]

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?

[tsightler]

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.

[Gostev]

Great, thanks for the update.

[Bazillus]

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é

[veremin]

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.