From 9f1af561c668ac244eb6799bc709aff84e402741 Mon Sep 17 00:00:00 2001 From: Michal Berger Date: Mon, 27 Dec 2021 13:19:12 +0100 Subject: [PATCH] scripts/core-collector: Don't limit core dump collection We should gather the core regardless of the RLIMIT_CORE setting. Also, don't limit number of parallel executions of the collector in case more than 2 processes crashed (unlikely to happen anyway, but just in case make sure we cover it). Lastly, wait a bit longer for the potential cores. Signed-off-by: Michal Berger Change-Id: Ic7de8f8000676122282469b729f45b235ab6f9ca Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10852 Tested-by: SPDK CI Jenkins Reviewed-by: Tomasz Zawadzki Reviewed-by: Jim Harris --- autotest.sh | 1 - scripts/core-collector.sh | 3 --- test/common/autotest_common.sh | 4 ++-- 3 files changed, 2 insertions(+), 6 deletions(-) diff --git a/autotest.sh b/autotest.sh index 8ac49378f..ffc5eada5 100755 --- a/autotest.sh +++ b/autotest.sh @@ -33,7 +33,6 @@ if [ $(uname -s) = Linux ]; then mkdir -p "$output_dir/coredumps" # set core_pattern to a known value to avoid ABRT, systemd-coredump, etc. echo "|$rootdir/scripts/core-collector.sh %P %s %t %c $output_dir/coredumps" > /proc/sys/kernel/core_pattern - echo 2 > /proc/sys/kernel/core_pipe_limit # make sure nbd (network block device) driver is loaded if it is available # this ensures that when tests need to use nbd, it will be fully initialized diff --git a/scripts/core-collector.sh b/scripts/core-collector.sh index 681ac8872..28155b394 100755 --- a/scripts/core-collector.sh +++ b/scripts/core-collector.sh @@ -55,9 +55,6 @@ if ((rlimit == 0xffffffffffffffff || rlimit > max_core)); then rlimit=$max_core fi -# Nothing to do -((rlimit == 0)) && exit 0 - # Clear path for lz rm -f "$core"{,.{bin,bt,gz,json}} diff --git a/test/common/autotest_common.sh b/test/common/autotest_common.sh index 92fe9a327..77cd6de47 100755 --- a/test/common/autotest_common.sh +++ b/test/common/autotest_common.sh @@ -652,11 +652,11 @@ function process_core() { # to see if there's any core queued up for writing. We could check if # collector is running and wait for it explicitly, but it doesn't seem # to be worth the effort. So assume that if we are being called via - # trap, as in, when some error has occurred, wait up to 5s for any + # trap, as in, when some error has occurred, wait up to 10s for any # potential cores. If we are called just for cleanup at the very end, # don't wait since all the tests ended successfully, hence having any # critical cores lying around is unlikely. - ((autotest_es != 0)) && sleep 5 + ((autotest_es != 0)) && sleep 10 local coredumps core