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

[milen-dzhambazov]

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?

• 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

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[chemwolf6922]

Hi @milen-dzhambazov .
The accept4 failed log is misleading. The error actually came from a prior poll call on the listen fd (with a 30s timeout). And there is no arbitrary limit in wsl on the vsock connections.
The issue looks more like a Windows side problem that caused the 30s timeout the poll call is waiting for. However, we do need the log to further analyze this.
Could you please follow the steps the bot provided to collect and share the log? Thanks.

[chemwolf6922]

I'm able to repro the issue by opening around 330 wsl sleep infinity sessions on my machine. It originated from a Windows side connect call to a hvsocket with the error WSAENOBUFS. This seems to be a hypervisor level resource constraint.

[milen-dzhambazov]

@chemwolf6922 thanks for looking into it. I'm surprised that this issue has so weak occurrence of reporting on the issue tracker. The few times I found something related to vsock, the users were just "meh, just restart WSL and it'll be fine", which in my case would involve restarting the docker desktop WSL integration and in the process - killing all of my dev stack containers. And I don't really have that huge of a stack... I mean... pretty small dev stack with a few consoles open at all times and hitting that issue all the time.

As mentioned in the report, I have far fewer than 330 open sessions...