GeezerVison

Problem

vlt_e2e_harness_npx_shim_forwards_the_args_after_the_package fails intermittently on Linux with Text file busy (os error 26). It's a harness self-test in vlt_e2e_common, so it is compiled into 7 test binaries (e2e_vlt, e2e_redirect_vlt_build, e2e_vendor_vlt_build, mode_migration_vlt, e2e_safety_vlt, e2e_hosted_production, e2e_vendored_production). It runs in every test (ubuntu-latest), test-release and coverage job and in every vlt e2e leg, which gives it many chances per PR to fail.

Evidence:

• run 36801003123: test-release failed on attempt 1 (job 110175102290) and passed on a rerun of the same SHA 18ff786b:

  test vlt_e2e_common::vlt_e2e_harness_npx_shim_forwards_the_args_after_the_package ... FAILED
  panicked at crates/socket-patch-cli/tests/vlt_e2e_common/mod.rs:2538:10:
  called `Result::unwrap()` on an `Err` value: Os { code: 26, kind: ExecutableFileBusy, message: "Text file busy" }
  

• Over the last 200 CI runs this was the only test-release failure that wasn't either broken on the branch (all four test jobs red on one SHA) or limited to one PR's branch.

Root cause

The test writes two shell scripts with fs::write, chmods them, and execs them right away. Linux refuses execve on a file that any process holds open for writing. If a sibling test thread forks while our write fd is open, its child inherits that fd and holds it until the child execs (the fd is O_CLOEXEC). Under load that window is long enough to overlap our exec.

Locally I reproduced it at both exec sites:

• our Command::new(npx).output() → ExecutableFileBusy at mod.rs:2538 (the CI failure)
• the npx shim's own exec of the fake socket binary → npx: 9: exec: …/socket: Text file busy, which surfaces as an assert_ok failure at mod.rs:777

A retry around our spawn, like exec_freshly_written in update_fixture.rs, only covers the first site. The second exec happens inside sh, where we can't retry it.

Fix

Add write_executable(path, body) to vlt_e2e_common. On Unix it writes the bytes to <path>.staged, has a child cp create path, removes the staged file, and chmod 755s the result. The test process never holds a writable fd to the executable, so no sibling fork() can inherit one. This closes the window itself instead of retrying. Windows keeps the plain write.

write_executable is used for:

• the fake socket script in the self-test
• the npx/vlt sh shims in write_shims_for. The real-vlt legs (write_shims) also exec these, so they had the same exposure.

Coverage is unchanged: no test is removed, skipped or weakened, and every assertion stays the same.

Proof

Stress harness (a scratch test binary, not committed): it includes vlt_e2e_common and adds 8 sibling tests that spawn /bin/true in a tight loop for 1.5 s. Each iteration runs them alongside the shim test with --test-threads=16.

Without the fork churn, e2e_vlt at --test-threads=32 passed 200/200 even before the fix, which is consistent with a load-dependent race.

Also run locally:

• vlt_e2e_harness* self-tests: pass in all 7 binaries; e2e_vlt non-ignored suite: 24 passed.
• cargo clippy -p socket-patch-cli --test <each of the 7> -- -D warnings: no findings in vlt_e2e_common. The only findings are pre-existing ones in prebuilt_common/mod.rs; that file is untouched, and CI's clippy job doesn't build test targets.
• rustfmt --check on the changed file.
• I couldn't run the real-vlt legs (--include-ignored vlt_pinned_matrix) here because the sandbox can't reach npmjs. The PR's e2e (*, *vlt*, …) CI jobs run them.

Where tests run

Nothing is moved or removed. Every test runs where it did before.

🤖 Generated with Claude Code

https://claude.ai/code/session_013p5RirmgQs47AecZUsbSmd

Generated by Claude Code