Windows Version

Microsoft Windows [Version 10.0.26200.7840]

WSL Version

2.6.3.0 (bug still present on master by inspection)

Are you using WSL 1 or WSL 2?

WSL 2

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 24.04

Other Software

Docker Desktop (WSL integration); agent-heavy workload — 5–15 concurrent sessions, frequent short wsl.exe -e calls

Repro Steps

No deterministic repro — the trigger is wslservice's per-session hvsocket connects partially failing (#40650 traced that to WSAENOBUFS on the Windows side). But the defect that turns a transient failure into a permanent leak is visible in the source, and easy to observe on any long-lived session-heavy machine:

1. Run a session-heavy workload for days.
2. ps -e -o pid,ppid,comm | awk '$3=="Relay"' — live relays are named Relay(<childpid>), stuck ones stay exactly Relay.
3. Watch the count grow (ours: 2 → 37 → 62 → 44 distinct per day, 131 total over 6 days), each stuck relay logging UtilAcceptVsock:244: Waiting for abnormally long accept every ~30 s.
4. Eventually new sessions hang (wsl.exe -e echo ok times out) while existing sessions and wsl --list --running still work — the accept4 failed 110 on new WSL sessions when vsock connection count is high — no tunable limit exists #40650 / New WSL sessions hang under memory pressure with vmbus_alloc_ring allocation failure #40795 end state.

Expected Behavior

Relay accept is bounded — precedent exists, the session-leader accept path passes SESSION_LEADER_ACCEPT_TIMEOUT_MS (30 s, common.h) and fails fast with accept4 failed 110. And a relay whose session leader died exits: there's nothing left to relay.

Actual Behavior

In CreateProcessUtilityVm (init.cpp ~1451 on tag 2.6.3, ~1481 on master) the relay thread calls UtilAcceptVsock(ListenSocket, SocketAddress) with no timeout → default Timeout = -1 (util.h) → the poll loop in util.cpp retries forever. If wslservice completes only some of the session's LX_INIT_UTILITY_VM_CREATE_PROCESS_SOCKET_COUNT connects, the relay blocks there indefinitely:

• never exits, even long after its session leader is dead;
• ignores SIGTERM (SigIgn: fffffffc7ff8fefe, per accept4 failed 110 on new WSL sessions when vsock connection count is high — no tunable limit exists #40650) — SIGKILL only;
• keeps its accepted hv_sock channels open, and each channel pins an order-7 (512 KB physically contiguous) vmbus_alloc_ring allocation (New WSL sessions hang under memory pressure with vmbus_alloc_ring allocation failure #40795). Enough stuck relays fragment guest memory until new channels can't allocate rings: new sessions fail, old ones work, and per the accept4 failed 110 on new WSL sessions when vsock connection count is high — no tunable limit exists #40650 field reports compact_memory doesn't recover it (rings are unmovable).

So a transient host-side connect failure compounds into a permanent guest-side leak.

Terminal stage on our machine: after ~6 days of accumulation the VM was cleanly shut down with processes still running (orderly systemd shutdown in the guest journal, no triggering event of any kind in the Windows System log) — all overnight work killed. Evidence in our #40650 comment.

Diagnostic Logs

Host-side ETW of the wslservice retry loop + guest journal data: #40650 (comment). More on request.

Workaround

The GC from #40650 (SIGKILL processes matching: cmdline /init, comm exactly Relay, no children, no /run/WSL/<pid>_interop, session leader dead, age > 10 min). One portability note: on a systemd distro orphaned relays reparent to pid 2 (the WSL /init), not pid 1 — the ppid check needs to accept both.

Related

#40650 (host-side trigger, no tunable limit), #40795 (memory mechanism), #41173 (interop busy-loop; sessions over sshd reportedly immune). Filing separately because the fix target differs: this is the guest-side lifecycle bug — unbounded accept, orphans never exiting — and it stays a bug even if the host-side limit gets raised.