Hi Frank, On Wed, 2022-04-13 at 15:09 -0400, Frank Ch. Eigler wrote: > > So maybe corruptin the sqlite database prevents a proper shutdown > > of the debuginfod process? > > Yeah, that test is a bit blunt and unpredictable. (We're literally > overwriting a piece of the database file that the process has open and > has random parts in cache.) I'm thinking this is not worth testing.
Does the attached look OK? Thanks, Mark
From 46e4d78de4a51b6e7ea2a2dba150ac9599c29c2f Mon Sep 17 00:00:00 2001 From: Mark Wielaard <m...@klomp.org> Date: Thu, 14 Apr 2022 13:26:57 +0200 Subject: [PATCH] tests: Don't try to corrupt sqlite database during test. In run-debuginfod-federation-sqlite.sh we used to try to corrupt the sqlite database while the debuginfod server was running and check it detected errors, but that was unreliably and slightly dangerous since part of the database was already mapped into memory. Instead trigger some some random activity, then trigger a shutdown. Signed-off-by: Mark Wielaard <m...@klomp.org> --- tests/ChangeLog | 5 +++++ tests/run-debuginfod-federation-sqlite.sh | 17 +++++++++-------- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/tests/ChangeLog b/tests/ChangeLog index 6cb0d649..e49bff05 100644 --- a/tests/ChangeLog +++ b/tests/ChangeLog @@ -1,3 +1,8 @@ +2022-04-14 Mark Wielaard <m...@klomp.org> + + * run-debuginfod-federation-sqlite.sh: Don't try to corrupt + sqlite database. + 2022-04-13 Aaron Merey <ame...@redhat.com> * Makefile.am (TESTS): Remove run-debuginfod-000-permission.sh diff --git a/tests/run-debuginfod-federation-sqlite.sh b/tests/run-debuginfod-federation-sqlite.sh index bb3cda12..d9321526 100755 --- a/tests/run-debuginfod-federation-sqlite.sh +++ b/tests/run-debuginfod-federation-sqlite.sh @@ -167,11 +167,11 @@ curl -s http://127.0.0.1:$PORT1/metrics | grep 'http_responses_after_you.*' # waiting. A few hundred ms is typical on this developer's workstation. ######################################################################## -# Corrupt the sqlite database and get debuginfod to trip across its errors -curl -s http://127.0.0.1:$PORT1/metrics | grep 'sqlite3.*reset' -dd if=/dev/zero of=$DB bs=1 count=1 - -# trigger some random activity that's Sure to get sqlite3 upset +# Trigger some some random activity, then trigger a clean shutdown. +# We used to try to corrupt the database while the debuginfod server +# was running and check it detected errors, but that was unreliably +# and slightly dangerous since part of the database was already mapped +# into memory. kill -USR1 $PID1 wait_ready $PORT1 'thread_work_total{role="traverse"}' 2 wait_ready $PORT1 'thread_work_pending{role="scan"}' 0 @@ -179,14 +179,15 @@ wait_ready $PORT1 'thread_busy{role="scan"}' 0 kill -USR2 $PID1 wait_ready $PORT1 'thread_work_total{role="groom"}' 2 curl -s http://127.0.0.1:$PORT1/buildid/beefbeefbeefd00dd00d/debuginfo > /dev/null || true -curl -s http://127.0.0.1:$PORT1/metrics | grep 'error_count.*sqlite' -# Run the tests again without the servers running. The target file should -# be found in the cache. kill -INT $PID1 $PID2 wait $PID1 $PID2 PID1=0 PID2=0 + +# Run the tests again without the servers running. The target file should +# be found in the cache. + tempfiles .debuginfod_* testrun ${abs_builddir}/debuginfod_build_id_find -e F/prog 1 -- 2.18.4
