I’m seeing some funky “new” (to me) behavior that I’m having trouble tracking down. Maybe y’all have seen it before. Using kernel 2.6.18-6-686 (debian etch), I can have a shell script open in vi, and suspend vi to run it. But on 2.6.26-1-686 (debian lenny) I get this error:
host:~/dir# ./shellscript -foo
-bash: ./shellscript: /bin/bash: bad interpreter: Text file busy
If I exit out of vi I can run the script just fine. I can also run the script with “sh shellscript”. strace reveals that the failure is happening super early on:
host:~/dir# strace ./shellscript -foo
execve("./shellscript", ["./shellscript", "-foo"], [/* 19 vars */]) = -1 ETXTBSY (Text file busy)
It looks like the kernel must be checking for exclusive advisory locks before proceeding. I have checked around Google and I see others have had the same trouble, and they’re always told to make sure the file isn’t open by some other process. But I can’t find where new behavior was introduced. Best I can gather, it’s just accepted as the norm now. Seems awfully weird to me.
UPDATE: As noted in the comments, the kernel isn’t doing flock before execve. It’s just preventing you from running commands if the file is open for writing. It’s old behavior. I only saw it now because old nvi didn’t keep the write file handle open (or at least, not in the same way) and new nvi does.
March 14th, 2009 at 12:00 am
Hmm, sure it’s not some security setting? Try ‘bash shellscript -foo’ and see if that works. I ran into this on some outsourced servers at work.
March 14th, 2009 at 7:32 am
Could be. I’ve checked sysctl -a for lock, exec, etc. “bash shellscript -foo” works fine. FWIW, the same thing happens with csh, further pointing at the kernel.
Edited: I think I’ve figured out what is going on (assuming the code I am looking at is the code that is in use). In fs/exec.c, do_exec() calls open_exec(), which calls deny_write_access(). That checks to see how many processes have the file open for writing, and if it is more than 0, it returns Text file busy.
It’s really old behavior, but I haven’t seen it until now because previous versions of nvi would open the input file with O_RDONLY, and the new version opens it O_RDWR (confirmed with strace).
You can duplicate the issue by running “cat >> shellscript” from the command line and them attempting to run the script in another window. The behavior seems to make more sense now (now that I know it’s not flock, that is) from a security standpoint.
October 29th, 2009 at 7:19 pm
I’m getting the “text file busy” when trying to mv or rm a .htm file:
server:/Scanned/OAO # rm ApplicationArchive.htm
rm: remove regular file `ApplicationArchive.htm’? y
rm: cannot remove `ApplicationArchive.htm’: Text file busy
why would this happen to a pure text file and not an executable.