I use NFS to edit files on servers. When these files are scripts with shebang lines, and I execute them, I get the "text file busy" error for about 5 seconds after I save each time.
The same problem is reproducible if a file is opened in vi (on 4.19 kernel), as follows:
:>test.sh chmod +x test.sh vi test.sh # Ctrl-Z to suspend vi ./test.sh # text file busy: ./test.sh
On 5.7 kernel the above vi example doesn’t produce the error but NFS write from 5.7 to 5.7 system still yields the "text file busy" error for 5 seconds after each save.
Per https://stackoverflow.com/questions/16764946/what-generates-the-text-file-busy-message-in-unix the error can be worked around by explicitly invoking the binary that runs the script:
I believe I can then write a script, call it
e, that will open the path given by the argument, see if the file begins with the shebang, if so parse the shebang line and invoke the binary in the shebang manually:
But, this begs the question: what am I paying my operating system for?
How can I configure Linux to execute files open for writing?
I grepped the 5.7 kernel source for
ETXTBUSY and it produced no hits.
Alternatively, as a less universal workaround, how can I make it so that writes over NFS immediately close the file being written instead of keeping it open for ~5 seconds?
The issue with vi (nvi, to be more precise), per a comment, is this one which is fixed in 1.81.6-16 on Debian (my 4.19 system has 1.81.6-15 and 5.7 system has 1.81.6-16). I would still like to figure out how to make NFS saves not produce the text file busy error.