accept4 failed 110 on new WSL sessions when vsock connection count is high — no tunable limit exists

Nobody has claimed this yet.

### Windows Version

Microsoft Windows [Version 10.0.26200.8457]

### WSL Version

WSL version: 2.7.3.0 Kernel version: 6.6.114.1-1 WSLg version: 1.0.73 MSRDC version: 1.2.6676 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26200.8457

### Are you using WSL 1 or WSL 2?

- [x] WSL 2
- [ ] WSL 1

### Kernel Version

6.6.114.1-microsoft-standard-WSL2

### Distro Version

Debian GNU/Linux 13 (trixie)

### Other Software

Client:
Version: 29.4.3
API version: 1.54
Go version: go1.26.2
Git commit: 055a478
Built: Wed May 6 17:06:42 2026
OS/Arch: linux/amd64
Context: default

Server: Docker Desktop 4.73.1 (226574)
Engine:
Version: 29.4.3
API version: 1.54 (minimum version 1.40)
Go version: go1.26.2
Git commit: 56be731
Built: Wed May 6 17:07:37 2026
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.2.3
GitCommit: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
runc:
Version: 1.3.5
GitCommit: v1.3.5-0-g488fc13e
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Client:
Version: 29.4.3
Context: default
Debug Mode: false
Plugins:
agent: Docker AI Agent Runner (Docker Inc.)
Version: v1.54.0
Path: /usr/local/lib/docker/cli-plugins/docker-agent
ai: Docker AI Agent - Ask Gordon (Docker Inc.)
Version: v1.20.2
Path: /usr/local/lib/docker/cli-plugins/docker-ai
buildx: Docker Buildx (Docker Inc.)
Version: v0.33.0-desktop.1
Path: /usr/local/lib/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v5.1.3
Path: /usr/local/lib/docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.47
Path: /usr/local/lib/docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Docker Inc.)
Version: v0.3.0
Path: /usr/local/lib/docker/cli-plugins/docker-desktop
dhi: CLI for managing Docker Hardened Images (Docker Inc.)
Version: v0.0.3
Path: /usr/local/lib/docker/cli-plugins/docker-dhi
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.31
Path: /usr/local/lib/docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.4.0
Path: /usr/local/lib/docker/cli-plugins/docker-init
mcp: Docker MCP Plugin (Docker Inc.)
Version: v0.42.0
Path: /usr/local/lib/docker/cli-plugins/docker-mcp
model: Docker Model Runner (Docker Inc.)
Version: v1.1.37
Path: /usr/local/lib/docker/cli-plugins/docker-model
offload: Docker Offload (Docker Inc.)
Version: v0.5.85
Path: /usr/local/lib/docker/cli-plugins/docker-offload
pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
Version: v0.0.25
Path: /usr/local/lib/docker/cli-plugins/docker-pass
sandbox: (Docker Inc.)
Version: v0.12.0
Path: /usr/local/lib/docker/cli-plugins/docker-sandbox
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /usr/local/lib/docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.20.4
Path: /usr/local/lib/docker/cli-plugins/docker-scout

Server:
Containers: 15
Running: 15
Paused: 0
Stopped: 0
Images: 15
Server Version: 29.4.3
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Discovered Devices:
cdi: docker.com/gpu=webgpu
Swarm: inactive
Runtimes: io.containerd.runc.v2 nvidia runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
runc version: v1.3.5-0-g488fc13e
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.6.114.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 31.34GiB
Name: docker-desktop
ID: 4000ea4f-9a2a-4dd3-96cb-fce34986b95b
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=unix:///var/run/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
::1/128
127.0.0.0/8
Live Restore Enabled: false
Firewall Backend: iptables

### Repro Steps

%USERPROFILE%\.wslconfig
```
[wsl2]
memory=28GB
swap=60GB
networkingMode=mirrored
```

```
# cat /etc/wsl.conf
[boot]
systemd=true
```

After a fresh WSL restart, with a normal developer workflow open (`docker compose up ...` foreground process with 18 containers, 14 ConEmu terminal tabs, 4 of which are interactive docker compose exec sessions into containers and a JetBrains ijent connection), the vsock connection count at baseline is already ~167. Any further docker compose exec call fails with:
```
WSL (PID - ) ERROR: UtilAcceptVsock:273: accept4 failed 110
```
Error 110 = ETIMEDOUT. No new WSL sessions can be established. The failure is slow and indicates a timeout.

No orphaned processes are present. All connections belong to live, legitimate sessions.

### Connection accounting

The vsock connection count and per-process breakdown are read with:

# Total connection count (subtract 1 for header line)
ss --vsock | wc -l

# Per-PID breakdown with process name and parent
ss -p --vsock | grep -oP 'pid=\K\d+' | sort | uniq -c | sort -rn | while read cnt pid; do
cmd=$(cat /proc/$pid/comm 2>/dev/null || echo "[gone]")
ppid=$(awk '{print $4}' /proc/$pid/stat 2>/dev/null)
printf "%4d conns pid=%-8s ppid=%-8s %s\n" "$cnt" "$pid" "$ppid" "$cmd"
done

Baseline output (fresh restart, before any new work):

7 conns pid=756 ppid=679 Relay(757)
7 conns pid=682 ppid=679 Relay(684)
7 conns pid=2113 ppid=2111 Relay(2115)
7 conns pid=2080 ppid=2079 Relay(2082)
7 conns pid=2006 ppid=2005 Relay(2008)
7 conns pid=1931 ppid=1930 Relay(1933)
7 conns pid=1858 ppid=1857 Relay(1859)
7 conns pid=1570 ppid=1569 Relay(1571)
7 conns pid=1475 ppid=1474 Relay(1478)
7 conns pid=1254 ppid=1245 Relay(1268)
7 conns pid=1149 ppid=1148 Relay(1150)
7 conns pid=1088 ppid=1087 Relay(1089)
7 conns pid=1067 ppid=1066 Relay(1068)
7 conns pid=1049 ppid=1044 Relay(1063)
4 conns pid=2086 ppid=2082 docker [docker compose exec -it php8.4-fpm bash]
4 conns pid=2012 ppid=2008 docker [docker compose exec -it php8.4-fpm bash]
4 conns pid=1938 ppid=1933 docker [docker compose exec -it php8.4-fpm bash]
4 conns pid=1860 ppid=1859 docker [docker compose exec -it php8.4-fpm bash]
4 conns pid=1063 ppid=1049 docker [docker compose up ...]
2 conns pid=2115 ppid=2113 ijent
2 conns pid=679 ppid=2 SessionLeader
... (13 × SessionLeader, each 2 conns)
2 conns pid=9 ppid=2 init
2 conns pid=2 ppid=1 init-systemd

Connection math per session:
- Each WSL session = 1 Relay (7 conns) + 1 SessionLeader (2 conns) = 9 connections minimum
- Each live docker CLI child adds 4 more connections
- 14 sessions × 9 = 126, plus 5 docker processes × 4 = 20, plus misc = ~167 total

This is normal usage — 14 terminals, 4 of which are inside Docker containers. No runaway processes, no leaks.

---
No tunable limit exists

Checked:
- /sys/module/vsock/parameters/ — no parameters exposed
- /sys/module/hv_sock/ — no parameters
- /sys/module/hv_vmbus/parameters/max_version — unrelated
- net.core.somaxconn (4096), net.core.netdev_max_backlog (1000) — TCP, not vsock
- .wslconfig — no documented vsock/hvsocket connection limit option
- Windows Registry under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization — no accept queue or connection limit keys

The WSL init binary (/init) contains the UtilAcceptVsock symbol and the exact error string, confirming the limit is enforced inside WSL's own relay infrastructure — not in a Linux kernel parameter that can be tuned from userspace.

---
Request

1. Expose a tunable for the vsock accept queue depth (either a .wslconfig key or a kernel module parameter) so users with many open terminals are not artificially capped.
2. Alternatively, reduce the per-session connection overhead below 7 connections per Relay — each session consuming 9 vsock connections makes the effective session limit far too low for typical developer workflows.

### Expected Behavior

I don't understand the whole shebang surrounding vsocks and win<->wsl communication, but I'd expect to be able to run docker compose stacks with 100 containers and 200 terminals as any VM could, let alone native Linux..

### Actual Behavior

Can barely run 18 consoles and 4 interactive docker exec consoles and it hits some weird limit preventing the opening of more consoles.

### Diagnostic Logs

_No response_

Start by investigating the WSL /init binary and its UtilAcceptVsock path, then compare the reported .wslconfig and /sys/module/vsock/parameters findings. Trace how the vsock accept queue and per-session connections are handled. Done means a supported limit or lower connection overhead prevents new WSL sessions from timing out under the reported workload.

Written by the indexing model from the issue text.