On Tue, May 20, 2025 at 01:47:22PM -0700, Vishal Verma wrote: > On Mon, 2025-05-19 at 12:28 -0700, alison.schofi...@intel.com wrote: > > From: Alison Schofield <alison.schofi...@intel.com> > > > > monitor.sh runs for 50 seconds and spends 48 of those seconds sleeping > > after sync. It sleeps for 3 seconds each time it restarts the monitor, > > and 3 seconds before checking for expected log entries. > > > > Add a wait_for_logfile_update() helper that waits a max of 3 seconds > > for an expected string to appear N times in the logfile using tail -F. > > > > Add a "monitor ready" log message to the monitor executable and wait > > for that message once after monitor start. Note that if no DIMM has an > > event flag set, there will be no log entry at startup. Always look for > > the "monitor ready" message. > > > > Expand the check_result() function to handle both the sync and wait > > that were previously duplicated in inject_smart() and call_notify(). > > It now waits for the expected N of new log entries. > > > > Again, looking for Tested-by Tags. Thanks! > > > > Signed-off-by: Alison Schofield <alison.schofi...@intel.com> > > Tested-by: Vishal Verma <vishal.l.ve...@intel.com> > Reviewed-by: Vishal Verma <vishal.l.ve...@intel.com> > > > > <snip> > > + > > + if ! timeout 3s tail -n +1 -F "$logfile" | grep -m "$expect_count" -q > > "$expect_string"; then > > + echo "logfile not updated in 3 secs" > > + err "$LINENO" > > + fi > > I was tempted to say something about a `set -o pipefail` before this, > and it might be nice to add one? > > It's not needed here since the grep will fail if the first part of the > pipeline fails, and there's no chance of the pipeline eating your error > in this case. > > But it might be good practice to do it for scenarios like > if ! cmd1 | cmd2 ... etc.
I looked at pipeline and it seems like it's be 1: grep no match 124: timeout expired 125+: anything else I'll experiment with it. > > >
