From ab58ff2928e9745bfcf63e6cc99f84b3aa5b1d23 Mon Sep 17 00:00:00 2001 From: Yannick Martin Date: Mon, 26 May 2025 15:05:42 +0200 Subject: [PATCH] fix api deadlock that can appears on two simultaneous actions With this mutex, we can have deadlock in the following case: 1/ Thread A processes a /v1/actions/acknowledge-problem request and locks the checkable 2/ Thread B processes a /v1/actions/add-comment and enters first the ConfigItem::ActivateItems() method and locks the static mutex there and starts the just created comment object, which triggers the OnCommentAdded() event. 3/ Thread A wants to activate the just created ack comment as well but since the mutex is already locked by TB, it blocks. 4/ Thread B's OnCommentAdded() even dispatch causes the IcingaDB::CommentAddedHandler() to be called and implicitly triggers full state update for the checkable. Now, the state serialization of that checkable (remember that's the same checkable currently locked by TA) also includes computing its severity, thus it calls either service->GetSeverity() or host->GetSeverity(). However, since computing the checkable severity (as of now) requires acquiring the object lock, and boom - they deadlock each other. --- lib/config/configitem.cpp | 3 --- 1 file changed, 3 deletions(-) diff --git a/lib/config/configitem.cpp b/lib/config/configitem.cpp index 9dc0f1aa2..6401b2d70 100644 --- a/lib/config/configitem.cpp +++ b/lib/config/configitem.cpp @@ -679,9 +679,6 @@ bool ConfigItem::CommitItems(const ActivationContext::Ptr& context, WorkQueue& u bool ConfigItem::ActivateItems(const std::vector& newItems, bool runtimeCreated, bool mainConfigActivation, bool withModAttrs, const Value& cookie) { - static std::mutex mtx; - std::unique_lock lock(mtx); - if (withModAttrs) { /* restore modified attributes */ if (Utility::PathExists(Configuration::ModAttrPath)) {