Spawning run_journal.exe from a Service: an Inherited stdin Pipe Stalls NX Startup ~35x

If a long-running server process (an MCP stdio server, a web service, a CI runner, any daemon whose own stdin is a pipe) spawns run_journal.exe without explicitly detaching stdin, NX batch startup goes from seconds to minutes — with no error output. It looks exactly like a hang.

Measured behavior (NX 2606, Windows 11, NVMe)

Parent process stdin	NX batch boot time
Console (running from a terminal)	~4 s
Inherited pipe (spawned by a stdio server), idle machine	~145 s
Inherited pipe, machine under heavy disk load	~6 minutes

The session boots correctly in every case — journals then run normally. But most orchestration code (and most humans) time out first, so the symptom reads as "run_journal hangs when launched from my service but works from a terminal."

Root cause

On Windows, subprocess.Popen without a stdin= argument lets the child inherit the parent's stdin handle. When that handle is a live pipe (e.g. the JSON-RPC channel of an MCP stdio server), something in NX's startup probes it and stalls for a long internal timeout before continuing. With a console or NUL stdin, startup proceeds immediately.

Fix

Always detach stdin when spawning NX batch processes:

subprocess.Popen(
    [r"D:\NX2606\NXBIN\run_journal.exe", journal_path],
    stdin=subprocess.DEVNULL,          # <- the load-bearing line
    stdout=log_file, stderr=subprocess.STDOUT,
    creationflags=0x08000000,          # CREATE_NO_WINDOW
)

(< NUL from cmd, or -RedirectStandardInput NUL-style equivalents, achieve the same from shells.) Apply it to one-shot subprocess.run calls too, not just persistent workers.

How this was diagnosed

A persistent worker journal wrote a ready file (with time.time()) as its last startup step. Comparing spawn timestamps, ready-file timestamps, and the orchestrator's poll deadline showed the worker consistently becoming healthy 30-150 s after the client had given up — the spawn context, not the machine or the journal, was the variable. Only spawns whose parent held a pipe stdin were slow; identical code from a terminal booted in 4 s.