[pve-devel] [PATCH cluster] config_change: correctly propagate $@ with nested locks

Fabian Grünbichler f.gruenbichler at proxmox.com
Tue Jul 16 14:18:58 CEST 2019


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 at proxmox.com>
---
 data/PVE/API2/ClusterConfig.pm | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/data/PVE/API2/ClusterConfig.pm b/data/PVE/API2/ClusterConfig.pm
index 6d23056..767bda9 100644
--- a/data/PVE/API2/ClusterConfig.pm
+++ b/data/PVE/API2/ClusterConfig.pm
@@ -172,7 +172,10 @@ 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($res) && defined($@);
 	} else {
 	    return $code->();
 	}
-- 
2.20.1





More information about the pve-devel mailing list