testsuite: avoid artificial corefile in test

[grondo]

Problem: In t3306-system-routercrash.t SIGSEGV is intentionally sent to a broker to test a broker crash, but this could leave a mysterious corefile in the test directory if the core file ulimit and system configuration allow it.

Call ulimit -c 0 before test_under_flux() to avoid the core file.

[chu11]

LGTM!

[grondo]

Thanks!

[codecov]

Codecov Report

Merging #5641 (afd5ecc) into master (6009b67) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5641      +/-   ##
==========================================
- Coverage   83.46%   83.45%   -0.01%     
==========================================
  Files         487      487              
  Lines       82931    82931              
==========================================
- Hits        69215    69210       -5     
- Misses      13716    13721       +5     

see 6 files with indirect coverage changes

[wihobbs]

Based on my understanding of ulimit, these settings will persist after this test, and we use ulimit -c unlimited in shell scripts before the test suite runs to try and capture core files occasionally in GitLab (we tried this with the libterminus tests for a while).

Not a big deal, it hasn't really helped us yet, but anyways...I noticed this is contained to t3306, is there a way to restore whatever settings were before after this test is over?

[wihobbs]

I guess in order to do ^ you'd have to save something like COREFILE_SIZE=$(ulimit -c) before changing ulimit -c 0, then restore at the end of the test with ulimit -c $COREFILE_SIZE. @grondo is that how you would go about this?

[grondo]

Based on my understanding of ulimit, these settings will persist after this test, and we use ulimit -c unlimited in shell scripts before the test suite runs to try and capture core files occasionally in GitLab (we tried this with the libterminus tests for a while).

ulimit(1) and the setrlimit(2) system call it uses only affect the current process and its descendants (see the NOTES section in the setrlimit(2) man page above).

You can test this for yourself by starting a new shell, adjusting the resource limit, then exiting and see the parent shell's resource limit is unchanged:

$ ulimit -c
16
$ bash 
$ ulimit -c unlimited
$ ulimit -c
unlimited
$ exit
exit
$ ulimit -c
16

Since ulimit -c unlimited is called within a sharness test, it will only persist for the tests within that one test script.

[grondo]

Though I should mention that all tests within a single sharness test do run in the same shell and what you did above would work I think if you wanted to adjust the ulimit for a single test_expect_success for example. (Alternately, you could run the test in a subshell)