In the course of updating software today I got the error "Text file busy", which got me wondering: Why is a Unix (or Linux) executable called a "text" file when that seems so counterintuitive and confusing? What's the history behind this? Probably has to do with the assembler "text" section I'm guessing, but why is that called "text"?

  • 4
    because of history -- it has always been that way. ETXTBSY with its translation "Text file busy" was already there in Unix v6 (45 years ago), as was the convention of referring to the instructions/code segment as "text segment". And BTW, "intuitive" is HIGHLY overrated. If someone's only argument to change anything is to make it more "intuititve", it's a clear signal that their idea should be immediately discarded ;-) – mosvy Mar 31 '20 at 21:26
  • Sorry, I didn't mean to imply that it should be changed. I was just observing that it's ironic that text files and executables are veritable opposites, and to call an executable a "text file" is rather amusing. – eewanco Mar 31 '20 at 21:32
  • 1
    Words and phrases should be taken as they are. Getting their etymology may be fun, but it's unlikely to shed any light on their meaning. But this is a problem with the localized error messages -- the German translation gets it right, the rest not so much (except maybe for the Japanese translation, which is simply "Text file busy" condition ;-) – mosvy Mar 31 '20 at 22:08
  • Oh I know exactly what it means. I'm just trying to have fun. Nothing wrong with that, right? – eewanco Mar 31 '20 at 22:10
  • Apologies; I did not intend to come across as defensive. – eewanco Mar 31 '20 at 23:20

In modern times, it's mostly just an artefact of the error symbol used for that error in POSIX: ETXTBSY, which strerror maps to "Text file busy".

Based on this answer on SO, one can infer that "text section" comes from an old usage of "binary text". However, ETXTBSY isn't only returned for binary programs, it can also be returned for things like active swapfiles (although my online swap reconfiguration patchset is coming this half, which will change this) and other state which the kernel cannot permit to be mutated at the current time.

Based on this, I'm not totally sure that the TXT in ETXTBSY really has much to do with the text section. I suspect it's more to do with the fact that "text" may be easier to unambiguously shorten into an error name than "file", although I didn't find evidence either way on this.

  • I don't get your point about binfmt_misc. Could you please give an example? I don't think that Linux will return ETXTBSY when someone is trying to overwrite a running she-banged script or executable loaded via the binfmt_misc mechanism. – mosvy Mar 31 '20 at 21:13
  • 1
    And it really won't. Not even when the kernel opened the executable and passed it to the interpreter via a file descriptor. (with the C or O flag, eg. like here). – mosvy Mar 31 '20 at 21:58
  • @mosvy Huh, you're right -- I misremembered how binfmt_misc works. I've updated my answer. Thanks! – Chris Down Mar 31 '20 at 23:40
  • It's right when you try to execve(2) any file which was opened for writing, not when trying to open(2) a file which was the image of an executable. The latter will only return ETXTBSY when the kernel itself is somehow using it as a "swapfile". – mosvy Mar 31 '20 at 23:44

ETXTBUSY is an artifact from historic UNIX versions.

It was originally used in case an attempt was made to modify a file that holds the text segment of a running executable binary using shared text and had a common used active copy in the swap space.

This later was extended by BSD to prevent modification of files that hold the text segment of running programs that use demanded page loaded features (paging not swapping) where a binary is not completely loaded at startup time, but rather each needed page is loaded on demand.

Modern OS like SunOS no longer use this error code since the new mmap() concepts from Bill Joy have been introduced in 1988. The reason was that the new orthogonal (generalized) understanding of mapping no longer used a separate text segment management in the kernel and there was no way to detect this kind of special usage.

Solaris now uses ETXTBUSY to flag modified ZFS snapshots.

Back to your question: such a "text file" is a file that holds the text segment (the code section) of a running program.


ETXTBSY is a standard posix system error and is also used in Linux.

Like EACCESS or EPERM, or EISDIR, it gives the reason for a failed inode access.

For one, there is this get_write_access() helper function. It checks some i_writecount field. This gets complicated.

static inline int get_write_access(struct inode *inode)
    return atomic_inc_unless_negative(&inode->i_writecount) ? 0 : -ETXTBSY;

This line shows a similar use of that error code:

mm/nommu.c:             return -ETXTBSY; /* not quite true, but near enough */

E.g. vfs_truncate() in fs.h has this test in the middle (between EISDIR and security)

error = get_write_access(inode);
if (error)
    goto mnt_drop_write_and_out;

The other ETXTBSY concerns swapfiles. vfs_fallocate() from fs/open.c:

 * We cannot allow any fallocate operation on an active swapfile
if (IS_SWAPFILE(inode))
    return -ETXTBSY;

Here the system is saying: sorry, I need that file (not: you don't have permissions).

Compare also:

]# grep busy  include/uapi/asm-generic/errno-base.h
#define EBUSY   16      /* Device or resource busy */
#define ETXTBSY         26      /* Text file busy */

Too bad you did not mention the context, or the error message at all

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.