When Move Disk is called for a container rsync starts copying it to a new destination. This initial rsync process gets killed when the Stop button gets pressed. At this moment the destination file is not fully copied and useless as a consequence. Our code already tries to remove it. However, rsync has forked and those forks are still accessing the destination file for some time. Thus, the attempt to remove it fails.
With the patch we wait for other processes to release the destination files. As we are in a mount namespace and protected by a config lock, those other processes should be children of rsync only. The waiting time was less than a second when I tried it. Afterwards, the existing remove procedure is carried out. Co-developed-by: Wolfgang Bumiller <[email protected]> Signed-off-by: Dominic Jäger <[email protected]> --- v2: System call is not a single string anymore v3: More exhaustive commit message src/PVE/LXC.pm | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm index 62b6b8c..4922fb0 100644 --- a/src/PVE/LXC.pm +++ b/src/PVE/LXC.pm @@ -2024,8 +2024,13 @@ my $copy_volume = sub { "--bwlimit=$bwlimit", "$src/", $dest]); }; my $err = $@; + + # Wait for rsync's children to release dest so that + # consequent file operations (umount, remove) are possible + while ((system {"fuser"} "fuser", "-s", $dest) == 0) {sleep 1}; + foreach my $mount (reverse @mounted) { - eval { PVE::Tools::run_command(['/bin/umount', '--lazy', $mount], errfunc => sub{})}; + eval { PVE::Tools::run_command(['/bin/umount', $mount], errfunc => sub{})}; warn "Can't umount $mount\n" if $@; } -- 2.11.0 _______________________________________________ pve-devel mailing list [email protected] https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
