fix(installer): avoid vLLM process false positives

[senthilr-nv]

Summary

DGX Station preparation treated unrelated diagnostic commands such as grep -qi vllm as active inference workloads. Process checks now require a vLLM executable or Python module launch while preserving existing container and port conflict checks.

Changes

• Recognize direct vLLM executables, python -m vllm modules, and docker-init vLLM commands.
• Ignore grep, rg, and shell diagnostics that only mention vllm as data.
• Apply the same classification to Station preparation and saved Local vLLM continuation.
• Add regression coverage for false-positive diagnostics, real workload detection, and model-name redaction.

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Quality Gates

• Tests added or updated for changed behavior
• Existing tests cover changed behavior — justification:
• Tests not applicable — justification:
• Docs updated for user-facing behavior changes
• Docs not applicable — justification: Existing Station documentation already limits the ownership flow to an existing vLLM workload. This fix restores that documented contract.
• Sensitive paths changed (security, policy, credentials, preflight, onboarding, inference, runner, sandbox, or messaging)
• Sensitive-path review completed or maintainer-approved waiver recorded — reviewer/approval link/justification: Maintainer implementation review is pending. The existing-vLLM ownership contract was accepted in PR fix(installer): hand off existing Station vLLM #7285.
• Non-success, skipped, or missing CI check accepted by maintainer — check name, approval link, and follow-up issue:

Documentation Writer Review

• Documentation writer subagent reviewed the completed changes
• Result: no-docs-needed
• Evidence: No documentation path changed. Existing DGX Station documentation already describes the intended active-vLLM workload contract, and this fix excludes unrelated diagnostic processes from that contract.
• Agent: Codex Desktop

DGX Station Hardware Evidence

• Tested on DGX Station
• Tested commit: a5f7262c7ea2aae5762deb30a7695e477aec8edb
• Station profile/scenario: pmgb300ws-0016, generic Ubuntu 24.04.4 ARM64 on a DGX Station GB300. A bounded read-only check used the exact committed script bytes against diagnostic process rows and the running managed vLLM.
• Result: PASS. grep, rg, and shell diagnostic rows did not block. The real managed vLLM still produced exit 12, Local vLLM continuation still detected it, ECC remained 0/0, and the managed container remained running.
• Supporting evidence: Exact-commit DGX Station classifier evidence

Verification

• PR description includes a Signed-off-by: line and every commit appears as Verified in GitHub
• Normal pre-commit, commit-msg, and pre-push hooks passed, or npm run check:diff passed when hooks were skipped or unavailable
• Targeted behavior tests pass for the current change set, or tests are marked not applicable above — command/result or justification: npx vitest run test/install-station-host-preparation.test.ts test/install-station-vllm-continuation.test.ts passed 65 tests. The related six-file Station suite passed five files; after building its required CLI artifacts, test/install-preflight.test.ts passed 94 tests.
• Applicable broad gate passed — npm test for broad runtime/test-harness changes; npm run check for repo-wide validation/coverage changes — command/result: Not run; the focused Station preparation and continuation suites cover this classifier change.
• Quality Gates section completed with required justifications or waivers
• No secrets, API keys, or credentials committed
• npm run docs builds without warnings (doc changes only)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: Senthil Ravichandran senthilr@nvidia.com

[coderabbitai]

📝 Walkthrough

Walkthrough

vLLM conflict detection now recognizes direct executables, Python module launches, and docker-init wrappers while ignoring diagnostic commands that only mention vLLM. Tests cover these process forms, conflict reporting, stop commands, and model-name redaction.

Changes

vLLM workload detection

Layer / File(s)	Summary
Expand process matching scripts/lib/station-vllm-conflict.sh, scripts/prepare-dgx-station-host.sh	Process scanning normalizes executable and argument fields and recognizes direct vLLM processes, Python -m vllm launches, and docker-init vLLM commands.
Validate active and diagnostic process cases test/install-station-host-preparation.test.ts, test/install-station-vllm-continuation.test.ts	Tests verify diagnostic commands are ignored, supported active process forms are detected, conflicts return status 12, stop commands are reported, and model names are omitted.

Estimated code review effort: 3 (Moderate) | ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: improving installer vLLM process detection to avoid false positives.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[senthilr-nv]

DGX Station hardware evidence

Tested commit: 486eeca5c4438ce301f25581c1770ccb1b89b855

Scenario: bounded read-only classifier check on pmgb300ws-0016, generic Ubuntu 24.04.4 ARM64, DGX Station GB300. The test used the exact committed script bytes. It did not stop or change a process, container, port, or service.

Result: PASS

• grep, rg, and shell diagnostic rows that mention vllm did not block Station preparation.
• The saved Local vLLM continuation classifier also ignored those diagnostic rows.
• The real managed vLLM remained detected by both classifiers.
• ECC remained 0 corrected / 0 uncorrected.
• The managed vLLM container remained running.
• Local evidence SHA-256: cfc3a28c7e165b85012d56c200126d9babca6d313d56faadaa100751ca695fd5

tested_commit=486eeca5c4438ce301f25581c1770ccb1b89b855
prepare_sha256=62dc6c120f4d8616df65b9cad64ef63a891e9dad623530f6895784075dbd9652
conflict_sha256=269cc6e090615fccf3630b3cacbde71a328f2921d42181d5bd664bd014fddc45
hostname=pmgb300ws-0016
os=Ubuntu 24.04.4 LTS
arch=aarch64
boot_id=5755e984-11c2-43d5-bac4-9c079694dcf4
product=Dell Pro Max with Station GB300
diagnostic_prepare_rc=0
[station-prepare] agent_inference_workloads=none port_8000=free
diagnostic_continuation_rc=1
actual_prepare_rc=12
[station-prepare] ERROR: vLLM inference workload is active: process=vllm. NemoClaw did not stop or modify it.
actual_continuation_rc=0
NVIDIA GB300, 610.43.02, 0, 0
managed_vllm_status=running
HARDWARE_TEST_RESULT=PASS

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/install-station-host-preparation.test.ts`:
- Around line 446-464: Extend the test case around
check_agent_and_inference_conflicts to include a docker-init command invoking
vLLM with a sensitive model name. Assert the same active-conflict status, PID
and stop-command reporting, and model-name redaction already checked for vLLM
and Python processes, using the scanner’s observable output boundary.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: d2021dc3-5391-4ac5-a740-4426d5f15519

📥 Commits

Reviewing files that changed from the base of the PR and between 12b9440 and 486eeca.

📒 Files selected for processing (4)

• scripts/lib/station-vllm-conflict.sh
• scripts/prepare-dgx-station-host.sh
• test/install-station-host-preparation.test.ts
• test/install-station-vllm-continuation.test.ts

[github-actions]

PR Review Advisor — No blocking findings reported

Advisor assessment: No blocking advisor findings reported
Next action: No advisor follow-up needed.
Findings: 0 blockers · 0 warnings · 0 suggestions

Model lanes

• GPT-5.6 Terra (primary): Completed · high confidence · 0 blockers · 0 warnings · 0 suggestions
• Nemotron 3 Ultra (second opinion): Completed · high confidence · 0 blockers · 0 warnings · 0 suggestions
• Model comparison: normalized findings match; normalized E2E selections differ; severity counts match.

Nemotron output stays in workflow artifacts and does not change the assessment above.

E2E guidance

Advisory only. E2E / PR Gate selects and runs jobs independently.

Recommended E2E: None

Workflow run details

This automated review informs maintainers. Warnings and suggestions do not require a response. A maintainer decides whether to merge.

[senthilr-nv]

DGX Station hardware evidence

Tested commit: a5f7262c7ea2aae5762deb30a7695e477aec8edb

Scenario: bounded read-only classifier check on pmgb300ws-0016, generic Ubuntu 24.04.4 ARM64, DGX Station GB300. The test used the exact committed script bytes. It did not stop or change a process, container, port, or service.

Result: PASS

• grep, rg, and shell diagnostic rows that mention vllm did not block Station preparation.
• The saved Local vLLM continuation classifier also ignored those diagnostic rows.
• The real managed vLLM remained detected by both classifiers.
• ECC remained 0 corrected / 0 uncorrected.
• The managed vLLM container remained running.
• Local evidence SHA-256: d3aae8c3df689235c11ffac09844e752d437d6b1378ea329796a328ffebe9626

tested_commit=a5f7262c7ea2aae5762deb30a7695e477aec8edb
prepare_sha256=62dc6c120f4d8616df65b9cad64ef63a891e9dad623530f6895784075dbd9652
conflict_sha256=269cc6e090615fccf3630b3cacbde71a328f2921d42181d5bd664bd014fddc45
hostname=pmgb300ws-0016
os=Ubuntu 24.04.4 LTS
arch=aarch64
boot_id=5755e984-11c2-43d5-bac4-9c079694dcf4
product=Dell Pro Max with Station GB300
diagnostic_prepare_rc=0
[station-prepare] agent_inference_workloads=none port_8000=free
diagnostic_continuation_rc=1
actual_prepare_rc=12
[station-prepare] ERROR: vLLM inference workload is active: process=vllm. NemoClaw did not stop or modify it.
actual_continuation_rc=0
NVIDIA GB300, 610.43.02, 0, 0
managed_vllm_status=running
HARDWARE_TEST_RESULT=PASS

[senthilr-nv]

Reviewed PRA-1 on a5f7262c7. The Python-module regex is not anchored after the interpreter; it already finds -m vllm later in the command line. The follow-up tests now prove python3 -u -m vllm... in host preparation and python3 -u -X dev -m vllm... in Local vLLM continuation. Both classify the workload as active, and the focused suite passes 65/65. No classifier broadening was needed.