debuginfod testing: SIGUSR2 vs "groom" metric synch

Previous code did not account for a groom job that was already
completed at startup, so the SIGUSR2-triggered one may not have
completed in time for the test.  The shell won the race condition on
most buildbot VMs, but a debian builder showed the error of our ways.

Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

diff --git a/tests/run-debuginfod-find.sh b/tests/run-debuginfod-find.sh
index 939826cd8b4212017e0a4d4f79a3468e8ea65589..1cc8f406e412be5f5a96ce6bd07b503c971ba72c 100755 (executable)
--- a/tests/run-debuginfod-find.sh
+++ b/tests/run-debuginfod-find.sh
@@ -269,7 +269,8 @@ RPM_BUILDID=d44d42cbd7d915bc938c81333a21e355a6022fb7 # in rhel6/ subdir, for a l
 rm -r R/debuginfod-rpms/rhel6/*
 kill -USR2 $PID1  # groom cycle
 # Expect 3 rpms to be deleted by the groom
-wait_ready $PORT1 'thread_work_total{role="groom"}' 1
+# 1 groom already took place at/soon-after startup, so -USR2 makes 2
+wait_ready $PORT1 'thread_work_total{role="groom"}' 2
 wait_ready $PORT1 'groom{statistic="file d/e"}' 3
 
 rm -rf $DEBUGINFOD_CACHE_PATH # clean it from previous tests