test_dtrace should try to terminate SystemTap gracefully before SIGKILL
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 停滞
- 技術スタック
- linux, python
調査の方向性
TraceBackend.trace() とレポートで言及されている test_dtrace テストから始め、次にタイムアウト処理が SystemTap プロセスグループにどのように到達するかを確認します。関連する DTrace/SystemTap テストを実行し、本当のタイムアウトが強制終了より前に正常な終了を可能にし、孤立したプロセスや一時ファイルを残さないことを確認します。
索引モデルが issue の本文から書いたものです。
説明
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
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 36k
- 平均マージ
- 1日 9時間
- マージ済み PR（30日）
- 558
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
python/cpython のほかの issue
-
docs pending
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
stdlib type-feature
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
stdlib type-feature
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
build type-bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
stdlib topic-email type-feature
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
-
🐛 Bug 🔔 Pending processing
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
jumpserver/jumpserver#17584 ·