From a9d32269743b21d6dc123b011cc9ee6221138756 Mon Sep 17 00:00:00 2001 From: Eric Weber Date: Fri, 3 May 2024 18:47:09 +0000 Subject: [PATCH] Don't fail on engine startup if unfreeze is stuck Longhorn 2187 Signed-off-by: Eric Weber --- app/cmd/controller.go | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/app/cmd/controller.go b/app/cmd/controller.go index 0f307fdcb..ec19a8c1d 100644 --- a/app/cmd/controller.go +++ b/app/cmd/controller.go @@ -179,10 +179,11 @@ func startController(c *cli.Context) error { } // If the engine failed during a snapshot, we may have left a frozen filesystem. We attempt to unfreeze here because - // we may not reach frontend startup (e.g. if there are no available backends). If we fail here, it is better not to - // continue startup. This can communicate to the user that there may be a frozen filesystem issue. + // we may not reach frontend startup (e.g. if there are no available backends). An unfreeze command may get stuck + // here for reasons unrelated to a frozen filesystem (e.g. there are outstanding I/Os to a crashed volume). Log a + // failure (e.g. a timeout), but continue. if err := util.UnfreezeFilesystemForDevice(util.GetDevicePathFromVolumeName(volumeName)); err != nil { - return errors.Wrapf(err, "failed to unfreeze filesystem") + logrus.WithError(err).Warn("Failed to unfreeze filesystem") } logrus.Infof("Creating volume %v controller with iSCSI target request timeout %v and engine to replica(s) timeout %v",