/usr/bin/perl：错误的解释器：文本文件忙
这对我来说是一个新问题：这个错误表明什么？
/usr/bin/perl: bad interpreter: Text file busy
当时有几个磁盘密集型进程正在运行，但我以前从未见过该消息 — 事实上，这是我第一次在尝试运行 Perl 脚本时遇到错误。经过几秒钟的等待后，我能够运行它，从那以后就再也没有看到这个问题，但如果能对此有一个解释那就太好了。
运行Ubuntu 9.04，文件系统是ext3。
This is a new one for me: What does this error indicate?
/usr/bin/perl: bad interpreter: Text file busy
There were a couple of disk-intensive processes running at the time, but I've never seen that message before—in fact, this is the first time that I can remember getting an error when trying to run a Perl script. After a few seconds of waiting, I was able to run it, and haven't seen the issue since, but it would be nice to have an explanation for this.
Running Ubuntu 9.04, file system is ext3.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我猜你遇到了
当您尝试执行 Perl 脚本（或任何其他类型的脚本）时，如果您的 Perl 脚本（或任何其他类型的脚本）处于打开状态以供写入，Linux 内核将生成一个
bad Interpreter: Text file busy错误。您没有说明磁盘密集型进程在做什么。其中之一是否有可能打开脚本进行读+写访问（即使它实际上没有写任何内容）？
I'd guess you encountered this issue.
The Linux kernel will generate a
bad interpreter: Text file busyerror if your Perl script (or any other kind of script) is open for writing when you try to execute it.You don't say what the disk-intensive processes were doing. Is it possible one of them had the script open for read+write access (even if it wasn't actually writing anything)?
发生这种情况是因为脚本文件已打开以供写入，可能是由尚未终止的恶意进程造成的。
解决方案：检查哪个进程仍在访问该文件，然后终止它。
例如：
在脚本名称上运行 lsof（列出打开的文件命令）：
通过 PID 杀死进程：
现在尝试再次运行该脚本。现在可以了。
This happens because the script file is open for writing, possibly by a rogue process which has not terminated.
Solution: Check what process is still accessing the file, and terminate it.
Eg:
Run
lsof(list open files command) on the script name:Kill the process by its PID:
Now try running the script again. It works now.
如果脚本是在 Windows 或任何其他具有不同“本机”行结尾的操作系统中编辑的，则它可能就像在第一行末尾“隐藏”
CR(^M)一样简单。 Vi 改进可以设置隐藏这个非本地行结尾。就我而言，我只需在 VI 中重新输入有问题的第一行，错误就消失了。If the script was edited in Windows, or any other OS with different "native" line endings, it could be as simple as a
CR(^M)"hiding" at the end of the first line. Vi improved can be set up to hide this non native line ending. In my case I simply re-typed the offending first line in VI and the error went away.这始终与 perl 解释器 (/usr/bin/perl) 无法访问有关。事实上，当 shell 脚本或 awk 或 #! 上的任何内容运行时，就会发生这种情况。脚本顶部的行。
原因可能有很多……权限、锁定文件、文件系统脱机等等。
这显然取决于问题发生时您运行它时发生的情况。但我希望答案就是您所寻找的。
This always has to do with the perl interpreter (/usr/bin/perl) being inaccessible. In fact, it happens when a shell script is running or awk or whatever is on the #! line at the top of the script.
The cause can be many things ... perms, locked file, filesystem offline, and on and on.
It would obviously depend on what was happening at the exact moment you ran it when the problem occured. But I hope the answer is what you were looking for.
如果您使用的是 gnu parallel 并且看到此错误，则可能是因为您从写入文件的同一位置流式传输文件...
If you are using gnu parallel and you see this error then it may be because you are streaming a file in from the same place that you are writing the file out...
我遇到了同样的问题，并且 grep 来查看正在使用该文件的内容不起作用。事实证明我只需要重新启动 Droplet，Viola 脚本现在就可以工作了。
I had this same issue and grepping to see what was using the file didnt work. turns out i just needed to restart the droplet and viola script now works.