Apache (2) throws “No such file or directory: exec

Question

I am working in Ubuntu 10.10 (Maverick Meerkat) and running my CGI script under Apache, but it is showing me the following error...

[Sat errorNo such file or directory: exec of '/usr/lib/cgi-bin/fst.cgi' failed [Sat Oct 22 02:56:45 2011] [error] [client 127.0.0.1] Premature end of script headers: fst.cgi

My script is

#!/usr/bin/perl
print "Content-type:text/html\n\n";
print "hello world";

I have set the permissions of the file...

I have also added the following line in file apache.conf:

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory /usr/lib/cgi-bin/>
   Options +ExecCGI
</Directory>

AddHandler cgi-script .cgi .pl

But still it is showing me the same error. I have done all the possible changes, but I didn't get any success...

Answer 1

You need to remove the "Windows' carriage return" which is produced when files are created inside a Windows environment.

this can be easily done by the command

dos2unix fst.cgi fst.cgi

The first fst.cgi is the file you want to convert and the second is the destination file name, which can remain the same.

Next step is to run the command

 chmod 755 fst.cgi

This will override the permission of the file and allow you to execute the file.

Good luck

Answer 2

I encountered the same error found in my /var/log/apache2/error_log. I finally realized that the Perl script was directly copied from my Windows system (via Parallels virtual machine) and it seems that the Windows' carriage return "\r\n" causes this error.

When I FTP this Perl script from Windows to Mac using ASCII mode to automatically convert "\r\n" into "\r", the same Perl script works correctly without any modification.

Answer 3

The error message "No such file or directory" doesn't come from Apache nor from Perl. When Apache is invoking the script, it passes the execution to the command line interpreter (CLI) of the system. This CLI opens the script file and reads the first line "#!/usr/bin/perl" (shebang line).

As Sam Tseng has elaborated, the file obviously contains a Windows line break character sequence: "\r\n" (hexcode: x0D x0A, symbols: CR LF). Now the CLI interpreter reads the line until the "\n" character. The CLI doesn't recognice the "\r" character, so it becomes part of the path "/usr/bin/perl \r" and is not anymore part of the line break.

Why does the option '-w' fix this issue?

When you add the option '-w' than the character '\r' becommes part of the argument "-w\r". The path to the Perl executable can now be found "/usr/bin/perl" and "-w\r" is passed as command line argument. However, Perl is nice and doesn't cause errors when handling the "-w\r" option.

Answer 4

• Make sure your script executes OK under apache user: # su -c /usr/lib/cgi-bin/fst.cgi apache
• Make sure the directory /usr/lib/cgi-bin has 755 permission
• Make sure the script /usr/lib/cgi-bin/fst.cgi has 755 permission

Answer 5

The same problem costs me almost a whole day! I would like to provide a possibility.

Both my PC and remote server OS is Ubuntu 16.04. And I am using FileZilla to transfer files from the PC to the remote server. The default transfer type is set as Auto which is the reason in my case.

The solution is that set the default transfer type as Binary. And the navigation path is: Edit -> Preferences -> Settings -> Transfers -> File Types -> Default transfer type:

Answer 6

I encountered the same problem several times - try to modify your shebang in the file to:

#!/usr/bin/perl -w

Now why this makes the script execute, beats me ... if you find out please let us know also.