Skip to main content
DevOps Insightsguides & answers

Linux · troubleshooting

Text file busy

Something tried to write into a program file while that program is running, and Linux refuses to change a running executable in place. Usually a deploy that copies a new binary over the old one while the service is still up.

Reproduced on Ubuntu 24.04, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 8 sections

Before you start

  • The path in the error, and whether a process is running from it.

Run this first

step 1 of 1
fuser -v PATH

Look for A process with access e (running it)

Lists processes using the file, and how.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

What was writing the file?

Cause space

2 of 2 still possible

  • A deploy copies the new binary over the running oneCommon
  • A build writes its output to a path a running process usesOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    fuser -v PATH

    Lists processes using the file, and how.

    Look for A process with access e (running it)

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

A deploy copies the new binary over the running one

Common

cp, scp or a build tool writes straight into the existing file while the service started from it is still running.

Confirm

fuser -v PATH 2>&1 || lsof PATH

A process running the file: access e in fuser, or FD txt in lsof

Fix

  • Write to a temporary name in the same directory, then rename: cp new-app app.new && mv app.new app, then restart the service.
  • Or use install -m 755 new-app app, which replaces the file the same way.
  • Or stop the service, copy, and start it again, if a short gap is acceptable.

A build writes its output to a path a running process uses

Occasional

A compiler or go build -o pointed at the binary a dev server or test is still running from.

Confirm

pgrep -af PROGRAM

The old build still running

Fix

  • Stop the old process first, or build to a new path and move it into place.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Linux will not let you open a running program's file for writing, because the running process is reading its code from that file. Replacing the file is allowed: write the new version to a different name, then rename it over the old one. The running process keeps the old file until it restarts.

Words used on this page

ETXTBSY
The kernel's error for this case. Text is an old name for a program's executable code.
Atomic rename
mv to a name in the same filesystem replaces the old file in one step; anyone opening the path gets either the old file or the new one, never half of each.
What is actually happening

Reproduced on 23 October 2026 on Ubuntu 24.04 with a copy of sleep running from a temporary directory. cp over it printed "cp: cannot create regular file './worker': Text file busy" and exited 1, and writing into it with cat > worker failed the same way.

Two ways of replacing it worked while it was still running: writing the new file under another name and mv-ing it into place, and install, which also replaces the file rather than writing into it. The running process carried on with the old code.

On macOS the same cp succeeded, so a deploy step tried on a Mac can pass and then fail on a Linux server.

How to tell this is your problem
WhereWhat you see
cp, scp, a deploy scriptcp: cannot create regular file 'APP': Text file busy
Shell redirectbash: ./app: Text file busy

How to know it is actually fixed

  • The new file is in place (ls -l shows the new size or date), and after a restart the service runs the new version.

Stopping it happening again

  • Deploy binaries with write-then-rename, or a versioned directory plus a symlink switch, never by writing over the live file.
  • Test deploy scripts on Linux, not only on a Mac, where this does not fail.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next