[an1310]

What does the PR do?

Adds a lifecycle test for a Python backend stub that stops responding during initialization. The init_unresponsive model stops its own stub during initialize() until the server gives up on it. The test checks that the load fails with the health error, the server exits, and no stub process or shared memory is left. It sets its own stub-timeout-seconds and is skipped on Windows.

Checklist

• I have read the Contribution guidelines and signed the Contributor License
  Agreement
• PR title reflects the change and is of format <commit_type>: <Title>
• Changes are described in the pull request.
• Related issues are referenced.
• Populated github labels field
• Added test plan and verified test passes.
• Verified that the PR passes existing CI.
• I ran pre-commit locally (pre-commit install, pre-commit run --all)
• Verified copyright is correct on all changed files.
• Added succinct git squash message before merging ref.
• All template sections are filled out.
• Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:

Check the conventional commit type
box here and add the label to the github PR.

• build
• ci
• docs
• feat
• fix
• perf
• refactor
• revert
• style
• test

Related PRs:

• fix: Kill a Python backend stub that outlives a failed instance launch python_backend#463

Where should the reviewer start?

qa/L0_backend_python/lifecycle/test.sh and qa/python_models/init_unresponsive/model.py.

Test plan:

• Ran the new block with the QA helpers in nvcr.io/nvidia/tritonserver:26.04-py3 on aarch64.
• It fails with the current Python backend and passes with fix: Kill a Python backend stub that outlives a failed instance launch python_backend#463.

Caveats:

• Requires fix: Kill a Python backend stub that outlives a failed instance launch python_backend#463.

Background

On Triton 26.04 (aarch64), Python model loads hung after a server restart and the server never started serving. gdb showed each load thread in StubLauncher::Launch() → ~ScopedDefer → WaitForStubProcess() → waitpid, with the stub processes alive and idle.

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• None

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge with the required Python backend fix.

Summary

Adds a Python backend lifecycle test for a stub that stops responding during initialization.

• The Python lifecycle suite now checks what happens when a model stub stops responding during initialization.

_{Reviews (2) · Last reviewed commit: "test: Require the failed-startup exit st..." · Reviewed by Greptile}