Allow polling for journal sync

Each error log commit forces a journal sync and needs to wait for the
sync to occur before allowing the commit to continue. The loop managing
the journal sync was only performing 2 iterations where the first
requests the sync and the second configures the inotify watch. However,
the polling necessary to wait for the inotify would never occur. This
bumps the managing loop to 3 iterations to allow the polling to occur on
the 3rd iteration.

Tested:
    The 5sec polling section of code is run on the 3rd iteration

Change-Id: If12c5b33849843b33bb252efd1eb88e0bc954d6d
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>

1 files changed, 12 insertions, 1 deletions

diff --git a/log_manager.cpp b/log_manager.cpp
index 2acbfad..fea2529 100644
--- a/log_manager.cpp
+++ b/log_manager.cpp
@@ -417,7 +417,18 @@ void Manager::journalSync()
         duration_cast<microseconds>(steady_clock::now().time_since_epoch())
             .count();
 
-    constexpr auto maxRetry = 2;
+    // Each time an error log is committed, a request to sync the journal
+    // must occur and block that error log commit until it completes. A 5sec
+    // block is done to allow sufficient time for the journal to be synced.
+    //
+    // Number of loop iterations = 3 for the following reasons:
+    // Iteration #1: Requests a journal sync by killing the journald service.
+    // Iteration #2: Setup an inotify watch to monitor the synced file that
+    //               journald updates with the timestamp the last time the
+    //               journal was flushed.
+    // Iteration #3: Poll to wait until inotify reports an event which blocks
+    //               the error log from being commited until the sync completes.
+    constexpr auto maxRetry = 3;
     for (int i = 0; i < maxRetry; i++)
     {
         // Read timestamp from synced file