Otherwise the writing of the unlock can overtake the configuration writing and if the wconfd gets killed forcefully in that moment an incorrect state is left on disk. If the calling job was not affected, then once it will retry it will believe it succeeded already because the lock is gone, hence leaving the configuration in an inconsistent state.
Signed-off-by: Klaus Aehlig <[email protected]> --- src/Ganeti/WConfd/Core.hs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/Ganeti/WConfd/Core.hs b/src/Ganeti/WConfd/Core.hs index 247d23b..59479e7 100644 --- a/src/Ganeti/WConfd/Core.hs +++ b/src/Ganeti/WConfd/Core.hs @@ -141,7 +141,8 @@ writeConfigAndUnlock cid cdata = do la <- readLockAllocation if L.holdsLock cid ConfigLock L.OwnExclusive la then do - CW.writeConfigWithImmediate cdata $ unlockConfig cid + CW.writeConfig cdata + unlockConfig cid return True else do logWarning $ show cid ++ " tried writeConfigAndUnlock without owning" -- 2.2.0.rc0.207.ga3a616c
