Orphaned backup job on Linux server?

[danswartz]

(this is just a curiosity thing - I have already cleaned everything up)

So, I have a CentOS7 server, which I use as a backup repository. It runs in a pacemaker cluster with another host, also running CentOS7. So I wanted to do an upgrade on the primary storage server. I logged into the cluster management GUI and told it to put the node into standby. What that would do is:

Deactivate the virtual IP it uses so vsphere can access virtual machine files on that datastore.
Export the ZFS pool.
The backup storage server would then:
Import the ZFS pool.
Activate the virtual IP for NFS.

I was surprised to see it say 'export failed!'. I tried to do so manually, and got an error that the filesystem in question was 'in use'. After some poking around, I discovered a couple of orphaned bash processes running perl scripts (I assume these are the datamovers or some such?) I killed them manually, and was then able to migrate the cluster resource to the backup node. I *think* the orphaning happened because the windows server 2008R2 VM that runs the Veeam software was rebooted in the middle of the night due to a windows update. So, my question: is there any way to make sure this doesn't happen again? e.g. is there some setting or something that will make these processes go away? I guess I can check periodically, but this is a real bummer, since if this happens, it ensures that the cluster software can't fail over in an unattended scenario (which is the whole point of running the cluster software.) Obviously, I can check every morning to make sure there are no orphan processes, but that is a real drag. If need be, I will install the NFS client software on the proxy, and access the backup repository via a shared folder. Thanks!

[foggy]

Hi Dan, those are Perl scripts that used to deploy Veeam data mover that performs actual data processing on the Linux repository, they are normally closed once the data mover starts. Data movers themselves have self-destruction mechanism and are cleaned up in case of connection drop, however, if it drops at the stage of deployment, when scripts are started and waiting for response from the started data mover, they are left in the system and there're no means to remove them later. However, the probability of this event is quite small, since the time scripts work is essentially short (compared to the overall job duration).

[danswartz]

Okay, thanks!