run-controllers reads removed session files after its monitored owner has exited

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

I maintainer di solito rispondono entro 1 giorno

@thomhurst ci sta già lavorando.

Dal 1/11/2026.

  • #342 di @thomhurst — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, python
Ambito
backend-api-design, cli

Direzione di ricerca

Read internal/commands/monitor.go, internal/dcpctrl/commands/run_controllers.go, and internal/hosting/command_service.go at the paired commit to understand cancellation and child-process ownership. Start by running the standalone reproduction against the released executable, then inspect the existing controlled-executor tests. Done means an exited monitored owner avoids session-file validation, a live owner with a missing kubeconfig still errors, and cancellation during launch has a safe ownership boundary.

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

Descrizione

run-controllers validates a deleted kubeconfig after its monitored owner has exited

Reproduced on Windows with the released DCP 0.26.6 executable, commit 6096b60432a281962920b8c7d2e9cba20118b750, distributed with Aspire 13.6.4. No application resource or container is needed.

run-controllers --monitor <pid> --monitor-identity-time <creation-time> --kubeconfig <missing-path> first establishes a monitor context. When the monitored owner has already exited, MonitorPid logs Error finding process and synchronously returns an already-canceled context. runControllers then validates the kubeconfig anyway and exits with an error because the owner has removed its session files.

Source at the paired commit:

  • MonitorPid explicitly cancels the context when the owner is absent.
  • runControllers does not observe that cancellation before requiring the kubeconfig.
  • newRunControllersService uses CommandServiceRunOptionDontTerminate.
  • CommandService.Run starts that child with a background context and returns success when the host context is canceled, without waiting for the child to finish using its session files.

The late-launch boundary is real: in a retained debug run, the apiserver announced controller launch at 16:48:47.917, began shutdown at 16:48:56.965, recorded successful process start at 16:48:57.705, and completed shutdown at 16:48:58.087. The child first logged at 16:49:00.003; it found the monitored parent gone, then reported the missing kubeconfig. The service's start announcement is not proof that the native child has executed.

Standalone reproduction

Create a short-lived parent process that blocks on stdin. While it is alive, retain an OpenProcess(SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION) handle and capture its creation time with GetProcessTimes. Release stdin and wait for the process to exit. Keep the handle open to prevent PID reuse. Verify WaitForSingleObject(handle, 0) == WAIT_OBJECT_0, then invoke the released dcp.exe with that PID, its exact creation time, and a nonexistent kubeconfig path.

Observed output:

info dcp Error finding process {"PID": <exited-owner>}
error dcp the program finished with an error {"ExitCode": 1, "error": "cannot set up connection to the API server without kubeconfig file: kubeconfig file does not exist at '<missing-path>'"}

Control: keep the same kind of parent alive, verify WaitForSingleObject(handle, 0) == WAIT_TIMEOUT, and run the command with its identity. It logs Started monitoring process, then correctly reports the missing kubeconfig and exits 1. The owner remains alive for the whole command.

Expected behavior: an already-canceled monitored lifetime exits without validating or opening session files. A missing kubeconfig under a live owner remains an error.

Suggested boundary and test

Observe ctrlCtx.Err() immediately after GetMonitorContextFromFlags and before accessing the kubeconfig or state store. The monitor helper's contract already states that an absent owner produces an immediately canceled context. Avoid changing resource-readiness deadlines or treating a live-owner missing kubeconfig as success.

There is also an in-flight launch ownership boundary worth testing: block Executor.StartProcess on a channel, cancel the service owner, then complete the launch while withholding the child exit callback. Current CommandService.Run returns nil while the child is still alive. It also invokes the executor when entered with an already-canceled context. A local controlled-executor regression confirms both behaviors with the exact released source; an experimental pre-cancel guard plus stop-and-join for cancellation during launch passes that regression. That experiment is not a complete fix: cancellation immediately after StartProcess returns and before the child initializes its monitor still needs a safe ownership boundary. Simply waiting for the child to notice parent exit can deadlock if the parent waits for the child first.

This report does not establish the cause of process startup delay, and fixing canceled-owner handling alone does not prove that short startup deadlines are reliable under contention.

Standalone Windows reproduction (Python 3)

Run python reproduce.py C:/path/to/dcp.exe. No container or application resource is created.

"""Probe paired DCP's canceled monitor boundary without creating resources."""
import ctypes
from ctypes import wintypes
import datetime
import hashlib
import json
import os
from pathlib import Path
import subprocess
import sys
import tempfile

ROOT = Path(tempfile.mkdtemp(prefix="dcp-canceled-owner-"))
DCP = Path(sys.argv[1]).resolve()
kernel = ctypes.WinDLL("kernel32", use_last_error=True)
kernel.OpenProcess.argtypes = (wintypes.DWORD, wintypes.BOOL, wintypes.DWORD)
kernel.OpenProcess.restype = wintypes.HANDLE
kernel.GetProcessTimes.argtypes = (wintypes.HANDLE, *(ctypes.POINTER(wintypes.FILETIME),) * 4)
kernel.GetProcessTimes.restype = wintypes.BOOL
kernel.WaitForSingleObject.argtypes = (wintypes.HANDLE, wintypes.DWORD)
kernel.WaitForSingleObject.restype = wintypes.DWORD
kernel.CloseHandle.argtypes = (wintypes.HANDLE,)
kernel.CloseHandle.restype = wintypes.BOOL


def case(parent_exits):
    name = "exited-owner" if parent_exits else "live-owner"
    folder = ROOT / ("native-" + name)
    folder.mkdir(exist_ok=True)
    owner = subprocess.Popen([sys.executable, "-c", "import sys; sys.stdin.buffer.read(1)"], stdin=subprocess.PIPE)
    handle = kernel.OpenProcess(0x00100000 | 0x1000, False, owner.pid)
    if not handle:
        raise ctypes.WinError(ctypes.get_last_error())
    try:
        times = [wintypes.FILETIME() for _ in range(4)]
        if not kernel.GetProcessTimes(handle, *(ctypes.byref(t) for t in times)):
            raise ctypes.WinError(ctypes.get_last_error())
        creation = (times[0].dwHighDateTime << 32) + times[0].dwLowDateTime
        epoch_ms = creation // 10000 - 11644473600000
        identity = datetime.datetime.fromtimestamp(epoch_ms / 1000, datetime.timezone.utc).isoformat(timespec="milliseconds").replace("+00:00", "Z")
        if parent_exits:
            owner.stdin.write(b"x")
            owner.stdin.flush()
            owner.wait(timeout=10)
        before = kernel.WaitForSingleObject(handle, 0)
        assert before == (0 if parent_exits else 258), before
        args = [str(DCP), "run-controllers", "--monitor", str(owner.pid), "--monitor-identity-time", identity,
                "--kubeconfig", str(folder / "no-kubeconfig")]
        env = os.environ.copy()
        env["DCP_DIAGNOSTICS_LOG_FOLDER"] = str(folder)
        env["DCP_DIAGNOSTICS_LOG_LEVEL"] = "debug"
        env.pop("DCP_LOG_SOCKET", None)
        result = subprocess.run(args, env=env, capture_output=True, timeout=30)
        (ROOT / (name + ".log")).write_bytes(result.stdout + result.stderr)
        return {"case": name, "ownerPid": owner.pid, "identityTime": identity, "retainedOwnerHandleWaitBefore": before,
                "retainedOwnerHandleWaitAfter": kernel.WaitForSingleObject(handle, 0), "nativeExitCode": result.returncode,
                "nativeOutput": (result.stdout + result.stderr).decode(errors="replace")}
    finally:
        if owner.poll() is None:
            owner.stdin.write(b"x")
            owner.stdin.flush()
            owner.wait(timeout=10)
        owner.stdin.close()
        kernel.CloseHandle(handle)


results = {"binary": str(DCP), "sha256": hashlib.sha256(DCP.read_bytes()).hexdigest(),
           "cases": [case(True), case(False)]}
(ROOT / "parent-exit-results.json").write_text(json.dumps(results, indent=2), encoding="utf-8")
print(json.dumps(results, indent=2))
Lingua principale
Go
Stelle
194
Fork
28
Merge medio
3g 5h
PR unite (30g)
38

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 microsoft/dcp

Tutte le issue di microsoft/dcp

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.