Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

serve: on Windows a managed engine that dies at startup is reported as success

Aperta
  • Qualcosa non va?
#467 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
cli, operating-systems

Direzione di ricerca

Start at spawn_managed_engine_child in apps/rocm/src/main.rs:6646 and compare its Windows path with the non-Windows child check. Read spawn_windows_no_inherit in crates/rocm-core/src/lib.rs:1167 and process_start_ticks in crates/rocm-core/src/proc_lifecycle.rs:307 and :314, then run the serve-18 scenario. Done means a startup-dead managed engine is detected on Windows, returns a nonzero result, and exposes the child diagnostic.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Symptom

On Windows, rocm serve exits 0 when the managed engine process dies during startup. Nothing is printed to stderr, and the command reports a launched service. On Linux and macOS the same failure is caught and reported with the child's log tailed into the error.

Root cause

spawn_managed_engine_child (apps/rocm/src/main.rs:6646) branches on platform after building the service record:

  • non-Windows — command.spawn(), then thread::sleep(200ms), then child.try_wait(). If the child has already exited it bail!s with managed_engine_startup_failure_detail(status, &record.log_path).
  • Windows — rocm_core::spawn_detached_no_inherit(..), which returns a bare u32 PID. There is no Child handle, and so no liveness or exit check of any kind. Control falls straight through to record.status = "running" and Ok(ManagedSpawn::Spawned { .. }).

The caller does not rescue it. start_managed_service waits up to 45s for HTTP readiness, then sets record.status = status_for_readiness(readiness) and returns Ok(ManagedLaunchReport { .. }) regardless of the readiness outcome — a timeout is recorded as a status, not raised as an error. So a dead child produces a successful command.

This has been the case since the initial import; it is not a recent regression.

There is no diagnostic either

On non-Windows the child's stdio is attached to the service log via attach_background_stdio(&mut command, Some(&record.log_path)). The Windows path reaches spawn_windows_no_inherit(..) with std_handles: None (crates/rocm-core/src/lib.rs:1167), so the detached child gets no stdout/stderr handles at all. A user therefore sees neither a non-zero exit nor a captured startup error.

A naive fix has a trap

The obvious repair — poll the PID for liveness — carries a PID-reuse race, and the guard that exists for exactly that is inert on Windows. record.supervisor_start_ticks comes from rocm_core::process_start_ticks, which reads /proc/{pid}/stat and returns None on every non-Linux target (crates/rocm-core/src/proc_lifecycle.rs:307 and :314). A correct fix needs a real process handle, or a Win32 process start-time identity, rather than a bare PID.

How it surfaced

PR #351 reworks the Lemonade recovery scenario to inject its failure inside the engine's Serve path — i.e. in the detached child. The seam it replaces injected the failure in the parent's Install RPC, which failed synchronously on every platform and so never exercised this gap. serve-18 consequently reports serve unexpectedly succeeded (rc 0, empty stderr) on the Windows lane while passing on the Linux GPU lanes. The scenario is correct; it is asserting behaviour the platform does not implement.

Observed vs inferred

Every file, line and branch cited above is read from the tree at b0d598d0. That the scenario's injected failure occurs inside the detached child and is invisible to the parent is inferred from those two branches plus the rc 0 / empty-parent-stderr evidence in the job log — I have no Windows host, and the job log does not include the child's service log.

Lingua principale
Rust
Stelle
46
Fork
13
Merge medio
3g 22h
PR unite (30g)
148

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ROCm/rocm-cli

Tutte le issue di ROCm/rocm-cli

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.