No, this won't happen simply because two Perl scripts are executing at the same time.
The more likely explanation is that the script itself is open for write while the operating system is trying to read its shebang line to determine the interpreter to use.
This can also happen if an external process is trying to upgrade or modify the Perl interpreter itself, or one of the shared libraries it depends on. Note that file permissions don't generally apply to superuser accounts, such as root, so any process running as superuser can still attempt to modify the Perl interpreter despite there being no +w
bits set.
(That said, most well-behaved operating system upgrade tools on POSIX-style operating systems will write the upgraded version of a binary to a new file on the same filesystem, close that file when done, and rename it over the original (an atomic operation) -- such that the inode attached at /usr/bin/perl
is itself never open for write. As such, on a well-behaved system, the error you're seeing isn't something that should ever come up in practice).
You can use the fuser
command to see who has a file open, either for your script or for its interpreter:
$ sudo fuser /usr/bin/perl -uv
USER PID ACCESS COMMAND
/usr/bin/perl: root 16579 f.... (root)python