oem: ibm: Assemble the image in a forked process
The assembling of the tarball image file is a long running process,
causing pldm to not reply to any other requests until it's done, causing
errors such as when the hypervisor tries to ping the bmc to determine if
it's running.
Move the assembling of the image to a forked process so that it runs in
the background. Move the assembling function to the code update class so
that it has access to the code update sensor to set it to error if an
failure occurs, since no parent process will wait for it.
Use double fork to avoid zombie tasks, this allows the grandchild to be
reparented to init.
Tested: Verified the hypervisor did not reset the BMC during an inband
update because it didn't receive a reply to its ping request.
Change-Id: I47d5fde1a1311e94d5b03f7fcf4c0ab15ba054e3
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
diff --git a/oem/ibm/libpldmresponder/inband_code_update.hpp b/oem/ibm/libpldmresponder/inband_code_update.hpp
index 7dbc735..7832579 100644
--- a/oem/ibm/libpldmresponder/inband_code_update.hpp
+++ b/oem/ibm/libpldmresponder/inband_code_update.hpp
@@ -168,6 +168,12 @@
*/
void deleteImage();
+ /** @brief Method to assemble the code update tarball and trigger the
+ * phosphor software manager to create a version interface
+ * @return - PLDM_SUCCESS codes
+ */
+ int assembleCodeUpdateImage();
+
virtual ~CodeUpdate()
{}
@@ -228,11 +234,5 @@
*/
int processCodeUpdateLid(const std::string& filePath);
-/** @brief Method to assemble the code update tarball and trigger the
- * phosphor software manager to create a version interface
- * @return - PLDM_SUCCESS codes
- */
-int assembleCodeUpdateImage();
-
} // namespace responder
} // namespace pldm