test_dtrace should try to terminate SystemTap gracefully before SIGKILL

Bug report

Bug description:

While checking out gh-156701 where the systemtap compilation was taking more than 10 seconds (hence an increase to timeout is required) I noticed also that the buildbot that I was testing at had too many D-state processes. That's possibly due to TraceBackend.trace() sending a SIGKILL immediately to the tracer process group when a timeout happens.

This prevents SystemTap and its children from performing normal cleanup. As mentioned in gh-156701 this left stap* temporary files behind, on the Fedora ppc64le buildbots, but also due repeated SystemTap timeouts, the buildbots had many orphaned staprun processes in Dstate, and the machines waited for them during shutdown.

From the system tap documentation: https://sourceware.org/systemtap/man/stap.1.html#abnormal-termination

One should avoid killing the stap process forcibly, for example with SIGKILL, because the stapio process (a child process of the stap process) and the loaded module may be left running on the system. If this happens, send SIGTERM or SIGINT to any remaining stapio processes, then use rmmod to unload the systemtap module.

Increasing the usability timeout should fix the premature timeout https://github.com/python/cpython/pull/156720, but genuine timeout still needs to be handled properly with SIGTERM and then if that fails a SIGKILL.

CPython versions tested on:

CPython main branch, 3.16, 3.15

Operating systems tested on:

Linux

Linked PRs

• gh-156753

Bắt đầu với TraceBackend.trace() và bài kiểm thử test_dtrace được đề cập trong báo cáo, sau đó xem xét cách xử lý timeout đến được nhóm tiến trình SystemTap. Chạy các bài kiểm thử DTrace/SystemTap liên quan và xác nhận rằng một timeout thực sự cho phép kết thúc một cách nhẹ nhàng trước khi kết thúc cưỡng chế, không để lại các tiến trình mồ côi hoặc tệp tạm thời.