"Text file busy" (ETXTBSY): writing to a running executable

What it is

ETXTBSY is documented in the open(2) manual page as the error returned when a program tries to open for writing, or truncate, a file that is currently mapped in as another process's program text — that is, a binary that is actively running. The kernel refuses because the running process's code pages are backed directly by that file; letting a write proceed in place would corrupt what is already mapped into memory. GNU cp reports it as cp: cannot create regular file '<path>': Text file busy. The reverse also exists: execve(2) returns ETXTBSY for a file that some process still holds open for writing, so starting a binary whose writer has not closed it yet fails with, for example, bash: ./app: Text file busy. Linux 6.11 and 6.12 temporarily stopped refusing writes to running executables (restored in 6.13); there an in-place overwrite silently succeeds and can crash the running program, so a missing error is no proof the overwrite is safe.

Why it matters

This shows up during naive deploy scripts: overwriting a long-running server binary or script in place, or cp-ing a new build over an executable that a supervisor is currently running, while nothing else appears wrong with the build itself.

How to apply

• Diagnose: fuser <path> or lsof <path> shows which process currently has the file open (as running program text), so you know what would need to stop, and whether that is expected.
• Fixes, least to most invasive:
  1. Stop the running process first, then overwrite the file — acceptable when a short outage is fine.
  2. Deploy by rename rather than in-place overwrite: write the new binary to a temporary path on the same filesystem, then mv it over the target. A rename is atomic on the same filesystem and does not touch the inode a running process already has mapped. GNU install(1) also avoids the error, but by removing the destination and then writing a new file, which leaves a short window where the path is missing or incomplete. The old process keeps running against the old, now-unlinked inode until it exits naturally, while the next invocation of the command picks up the new file immediately, with no busy error and no downtime.
  3. Avoid cp or truncating redirections (>, opening with O_TRUNC) onto a path that might be the currently running binary in any deploy script; standardize on copy-then-rename everywhere binaries are updated.
• Not reliable: retrying the write in a loop. The file stays busy for as long as the process keeps running, which may be indefinite for a long-lived server, so retrying does not resolve anything; only changing the write strategy does.

Pitfalls

• Assuming the error means the file is corrupted or permissions are wrong; it is neither — the file is simply in active use as executable text.
• Expecting the error to protect running shell scripts: the kernel does not lock a script's file, so an in-place overwrite succeeds and bash, which reads scripts incrementally, may execute the new bytes mid-run. Deploy scripts by rename too.