API: correctly propagate $@ with nested locks

PVE::Cluster::cfs_lock_file sets $@ and returns undef for all errors,
including when $code dies. PVE::Tools::lock_file runs $code inside an
eval as well, so just setting $@ is not enough when nesting these two
types of locks.

re-die with the inner error to actually propagate error messages and
fail instead of proceeding. this triggered (probably among other cases)
when attempting to join an existing cluster without specifying all
needed links.

Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>

diff --git a/data/PVE/API2/ClusterConfig.pm b/data/PVE/API2/ClusterConfig.pm
index 6d23056a6b2a7b2a3c6ba299d46334c0c1d870cf..0daa9e76199fa7b510b16703d127fe601fa2bad2 100644 (file)
--- a/data/PVE/API2/ClusterConfig.pm
+++ b/data/PVE/API2/ClusterConfig.pm
@@ -172,7 +172,11 @@ my $config_change_lock = sub {
        PVE::Cluster::cfs_update(1);
        my $members = PVE::Cluster::get_members();
        if (scalar(keys %$members) > 1) {
-           return PVE::Cluster::cfs_lock_file('corosync.conf', 10, $code);
+           my $res = PVE::Cluster::cfs_lock_file('corosync.conf', 10, $code);
+           # cfs_lock_file only sets $@
+           # lock_file does not propagate $@ unless we die here
+           die $@ if defined($@);
+           return $res;
        } else {
            return $code->();
        }