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"?
3 Answers
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.

- 125,559
- 25
- 270
- 266
-
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. – Mar 31 '20 at 21:13 -
1And 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
orO
flag, eg. like here). – 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". – 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.

- 19,173
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
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 ;-) – Mar 31 '20 at 21:26"Text file busy" condition
;-) – Mar 31 '20 at 22:08