`--cache`: fspy `seccomp(NEW_LISTENER)` returns EBUSY when ancestor has user-notify listener (WSL2)

[david-pw]

Describe the bug

When running vp run --cache build, the --cache flag is throwing an odd error Error: spawn EBUSY.

Claude is telling me that this might be environmental, so I'd want to check first if this is a vp issue before trying to create a minimally reproducible repo. Claude wrote a bunch of stuff, but it reads like Unix jargon to me, so I'll spare you guys the "analysis".

Symptom
Any task run under vp run --cache that spawns the esbuild service binary fails with:

  Error: spawn EBUSY
      at ChildProcess.spawn (node:internal/child_process:421:11)
      at ensureServiceIsRunning (.../esbuild/lib/main.js:1978)

When running vp run build without --cache, the command runs as expected

Tried

• Killing all node processes, and running the vp command with --cache again. Same issue
• Installing latest vp command tools curl -fsSL https://vite.plus | bash. Same issue
• Turning it on and off again wsl --shutdown. Fixes the issue

Not sure why restarting WSL fixes it? Another of my developers who works in WSL is also experiencing the same issue, so it doesn't seem isolated to my machine.

Reproduction

https://github.com/david-pw

Steps to reproduce

Minimal repro

In any package whose build invokes esbuild (e.g. storybook build loading .storybook/main.ts):

vp run -F build # works
vp run --cache -F build # fails with spawn EBUSY

System Info

Environment
  - vp v0.1.22 (also reproduced with 0.1.21); local vite-plus v0.1.20
  - WSL2 Ubuntu 22.04.5, kernel 6.6.114.1-microsoft-standard-WSL2
  - Node v24.11.1
  - Root FS ext4 (/dev/sdd); /tmp is also ext4 (not tmpfs), repo on /home/...
  - Baseline Seccomp: 2 on every process inherited from /sbin/init (standard WSL2 + systemd)




VITE+ - The Unified Toolchain for the Web

Environment:
  Version       24.11.1
  Source        .node-version
  Source Path   /home/david-pw/dev/MyProject-product/MyProject.Tui/.node-version
  Project Root  /home/david-pw/dev/MyProject-product/MyProject.Tui

Tool Paths:
  node  /home/david-pw/.vite-plus/js_runtime/node/24.11.1/bin/node
  npm   /home/david-pw/.vite-plus/js_runtime/node/24.11.1/bin/npm
  npx   /home/david-pw/.vite-plus/js_runtime/node/24.11.1/bin/npx



VITE+ - The Unified Toolchain for the Web

vp v0.1.22

Local vite-plus:
  vite-plus  v0.1.20

Tools:
  vite             v8.0.10
  rolldown         v1.0.0-rc.17
  vitest           v4.1.5
  oxfmt            v0.46.0
  oxlint           v1.61.0
  oxlint-tsgolint  v0.22.0
  tsdown           v0.21.10

Environment:
  Package manager  pnpm v10.29.2
  Node.js          v24.11.1 (.node-version)

Used Package Manager

pnpm

Logs

➜  MyProject ✗ vp run --cache build               
VITE+ - The Unified Toolchain for the Web

~/packages/tui-react$ storybook build

┌  Building storybook v10.2.10
│
◇  Cleaning outputDir: storybook-static
│
■  SB_CORE-SERVER_0007 (MainFileEvaluationError): Storybook couldn't
│  evaluate your .storybook/main.ts file.

│  Original error:
│  Error: spawn EBUSY
│  at ChildProcess.spawn (node:internal/child_process:421:11)
│  at Object.spawn (node:child_process:796:9)
│  at ensureServiceIsRunning
│  (/home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/esbuild@0.27.3/node_modules/esbuild/lib/main.js:1978:29)
│  at transform
│  (/home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/esbuild@0.27.3/node_modules/esbuild/lib/main.js:1878:37)
│  at load
│  (file:///home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/storybook@10.2.10_@testing-library+dom@10.4.0_prettier@3.8.1_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/storybook/dist/bin/loader.js:77:113)
│  at async nextLoad (node:internal/modules/esm/hooks:785:22)
│  at async AsyncLoaderHooksOnLoaderHookWorker.load
│  (node:internal/modules/esm/hooks:416:20)
│  at async MessagePort.handleMessage
│  (node:internal/modules/esm/worker:251:18)
│  at loadMainConfig
│  (file:///home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/storybook@10.2.10_@testing-library+dom@10.4.0_prettier@3.8.1_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/storybook/dist/_node-chunks/chunk-URMZXQZT.js:11709:11)
│  at async buildStaticStandalone
│  (file:///home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/storybook@10.2.10_@testing-library+dom@10.4.0_prettier@3.8.1_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/storybook/dist/core-server/index.js:6239:16)
│  at async withTelemetry
│  (file:///home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/storybook@10.2.10_@testing-library+dom@10.4.0_prettier@3.8.1_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/storybook/dist/_node-chunks/chunk-S3MWHNYJ.js:218:12)
│  at async build
│  (file:///home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/storybook@10.2.10_@testing-library+dom@10.4.0_prettier@3.8.1_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/storybook/dist/bin/core.js:2679:3)
│  at async _Command.<anonymous>
│  (file:///home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/storybook@10.2.10_@testing-library+dom@10.4.0_prettier@3.8.1_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/storybook/dist/bin/core.js:2821:7)
│
▲  Failed to load preset:
│  "/home/david-pw/dev/MyProject-product/MyProject.Tui/packages/tui-react/.storybook/main.ts"
│
■  Error: spawn EBUSY
│  at ChildProcess.spawn (node:internal/child_process:421:11)
│  at Object.spawn (node:child_process:796:9)
│  at ensureServiceIsRunning
│  (/home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/esbuild@0.27.3/node_modules/esbuild/lib/main.js:1978:29)
│  at transform
│  (/home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/esbuild@0.27.3/node_modules/esbuild/lib/main.js:1878:37)
│  at load
│  (file:///home/david-pw/dev/MyProject-product/MyProject.Tui/node_modules/.pnpm/storybook@10.2.10_@testing-library+dom@10.4.0_prettier@3.8.1_react-dom@19.2.4_react@19.2.4__react@19.2.4/node_modules/storybook/dist/bin/loader.js:77:113)
│  at async nextLoad (node:internal/modules/esm/hooks:785:22)
│  at async AsyncLoaderHooksOnLoaderHookWorker.load
│  (node:internal/modules/esm/hooks:416:20)
│  at async MessagePort.handleMessage
│  (node:internal/modules/esm/worker:251:18)
│
└  Storybook exited with an error

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue for the same bug.
• Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
• The provided reproduction is a minimal reproducible example.

[david-pw]

Claude's analysis of my WSL2 setup

Update: root cause is fspy's seccomp install, not esbuild

Dug deeper with strace -f -e trace=execve,seccomp,prctl,clone,clone3 vp run --cache -F <pkg> build. The actual failing syscall isn't execve — it's fspy's seccomp filter install:

prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)                                = 0
seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER,
        {len=75, filter=0x...})                                       = -1 EBUSY
+++ exited with 127 +++

The fspy spawn helper exits 127, libuv preserves errno, Node surfaces it as spawn EBUSY — which is why it looks like an execve failure in the JS stack trace coming from esbuild.

Why the kernel returns EBUSY here

kernel/seccomp.c's seccomp_set_mode_filter() runs has_duplicate_listener() over the calling task's filter chain and returns -EBUSY if any ancestor filter already has a user-notify listener attached. This is intentional — it
prevents deadlocks between layered user-notify supervisors.

On WSL2, /sbin/init (PID 1) shows Seccomp: 2 and that filter is inherited by every descendant — verified by checking /proc/<pid>/status for unrelated processes like head, bash, login shells, etc. WSL's own /init interop layer is
almost certainly holding a user-notify listener on PID 1. So fspy can never install a NEW_LISTENER filter anywhere on the system — every --cache task fails the first time fspy tries to install its supervisor.

This also explains why wsl --shutdown sometimes fixes it: there appears to be a boot-time race in whether the interop listener is installed before users run vp.

Ruled out

• ❌ Process holding esbuild binary — fresh cp to /tmp/esbuild-copy-$$ fails the same way
• ❌ Stale /tmp/fspy/*.dylib — deleted, vp regenerates identical-hash dylib, identical failure
• ❌ Docker seccomp layering — stopped all 10 local containers, identical failure. The inherited Seccomp: 2 comes from PID 1, not Docker.

Suggested fixes for fspy (none require kernel changes)

1. Probe + fallback. At startup, try a tiny no-op seccomp(NEW_LISTENER) install. On EBUSY, skip the seccomp path for the rest of the process tree and continue with LD_PRELOAD-only file tracking. For typical JS/Node task graphs LD_PRELOAD
   coverage is sufficient (it misses only statically-linked binaries doing direct syscall(...)).
2. WSL2 auto-detect. Check /proc/sys/fs/binfmt_misc/WSLInterop or uname -r for microsoft-standard-WSL2; default to LD_PRELOAD-only on those systems without the failing probe.
3. Safe-degrade. If neither tracker can be installed, disable caching for the run with a clear log line instead of crashing arbitrary user code with spawn EBUSY.
4. Better error. Even with the current behavior, catching the EBUSY at the fspy layer and printing fspy: cannot install seccomp filter (ancestor has user-notify listener — common on WSL2); --cache unsupported in this environment would
   save the next person several hours.

Same class of failure should hit any sandboxed CI runner that already has a user-notify listener installed, not just WSL.

Filtered strace (~330 lines) and the kernel code path reference available if useful.