James Burry: > Here is the kernel message produced : Thanx for the call trace. Here is my current guess.
Brief scenario - chmod sets "this file is being changed" mark to the file inode. - exec(./a.sh) checks the mark, and rejects as "the file should not be changed during the execution." Rather deep note - chmod activates the aufs copy-up internally. the copied-up file, which is a newly created one on the upper writable branch, is opened with O_WRONLY flag. That is equivalent to set "this file is being changed" mark. - The mark will be cleared when the file is closed, ie. when the copy-up is completed. - But linux has a neat feature "delayed fput." It is a feature to postpone the closing file and to gain a better performance. - As the mark is cleared when the file is closed, the mark remains until this neat feautre is activated. - when exec(./a.sh) is issued, the mark MAY remains. In this case, the result will be ETXTBSY obviously. This is just my guess, but here is a patch to force closing the file after the internal copy-up. Would you apply it and test again? J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
