The shrinking role of ETXTBSY
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
By Jonathan Corbet August 19, 2021 Unix-like systems abound with ways to confuse new users, many of which have been present since long before Linux entered the scene. One consistent source of befuddlement is the "text file is busy" (ETXTBSY) error message that is delivered in response to an attempt to overwrite an executable image file. Linux is far less likely to deliver ETXTBSY results than it once was, but they do still happen on occasion. Recent work to simplify the mechanism behind ETXTBSY has raised a more fundamental question: does this error check have any value at all?
The "text" that is busy in this case refers to a program's executable code — it's text that is read by the CPU rather than by humans. When a program is run, its executable text is mapped into the running process's address space. When this happens, Unix systems have traditionally prevented the file containing that text from being modified; the alternative is to allow the code being run to be changed arbitrarily, which rarely leads to happy outcomes. For extra fun, the changed code will only be read if it is faulted into RAM, meaning that said unhappy outcomes might not happen until hours (or days) after the file has been overwritten. Rather than repeatedly explain to users why their programs have crashed in mysterious ways, Unix kernel developers chose many years ago to freeze the underlying file while those programs run — leading to the need to explain ETXTBSY errors instead.
