Internal server errors with Perl CGI scripts.
This text shows some common causes of internal server errors with Perl CGI scripts, based on my own experiences, mostly things that I had forgotten to do before running my script (developed and tested on Windows) on my Linux (Ubuntu) VPS webserver. The tutorial should mostly applies to other operating systems, too.
It's good practice to always add the line
use CGI::Carp "fatalsToBrowser";
to your CGI scripts. This results in the display of the Perl error messages in the web browser window and you have a direct clue what's wrong with your script. In
order to catch script errors from the beginning, the creation of the CGI object should be done with the first lines of your source code, using something like this:
my $cgi = new CGI;
print "Content-Type: text/html\n\n";
print '<!DOCTYPE html>', "\n\n";
If despite of this you get an Internal server error (error 500), than the reason isn't normally a mistake in your script, but some problem with the execution of the script, Apache not being able to make Perl run the script and therefore generates the error 500.
A common reason for this situation is that we forgot to make the script executable (this may easily happen when, as Windows user, we want to run a CGI script on Linux). So, after uploading a script, be sure that the "executable" file permission is set for everyone. If you use the FTP client WinSCP, you can do this by selecting the file in the remote files tab, choosing Properties from the menu and, in the opening Properties dialog box, selecting the 3 "executable" checkboxes (with all other file permissions let at their defaults, this will correspond to a chmod 755).
Another common reason is some problem with the shebang line. The most obvious issue is that you developed the
script on Windows and forgot to replace the path to your Windows Perl interpreter to the one on your Linux server. As you probably know, on
Linux, the shebang line is normally
#!/usr/bin/perl
The shebang line may cause another problem when running a script written on Windows on a Linux web server. As Windows uses CR + LF as end of line marker, whereas Linux
just uses LF, the shebang line may not be understood on Linux, and Apache not knowing what to do with the Perl script, generates an error 500. The simplest way to avoid
all problems is to transform the Windows end-of-line markers to Unix end-of-line markers. With the freeware editor
Notepad++ this may be done by simply choosing the corresponding command in the
Edit menu.
Let's also mention that the reason for a script, that works on your local server, not working on your Internet server may be a Perl module that is not installed on the server, or that cannot be found. Also pay attention when passing from Windows to Linux if you access some text or other files from within the script: Do not forget to change the path of the files accessed by Perl.
In the case of an error 500, there is no indication, of what this error could be, displayed in the web browser. However, you can view the log files on your server machine.
On my Ubuntu Server VPS (running with Hestia Control Panel), this file is called streetinfo.lu.error.log ("streetinfo.lu" being the DNS domain
name) and is located in the directory /home/allu/web/streetinfo.lu/logs ("allu" being the user under whom the domain streetinfo.lu has been
created in Hestia). If you want to access the error log with your main Ubuntu user (normally different from the "web user"), be aware that there is no problem to
cd across the directory structure, but that this user has no permission to list these directories, nor to view the files. Unless you give
them super-user privileges by preceding the terminal commands with sudo. So (supposing not to remember all directory and file names), we
can run the following commands to view the error log content:
cd /home/allu/web/streetinfo.lu
sudo ls
cd logs
sudo ls
sudo less streetinfo.lu.error.log
Note: You cannot execute a su command on Ubuntu, but there is a possibility to open a root
terminal (and thus having full access to all files and directories) by issuing the command:
sudo -i
One of the error messages in relationship with an internal server error commonly found in the error log is End of script output before headers. This indicates that the script could not be run, what is in particular true if you forgot to make it executable.
If you find this text helpful, please, support me and this website by signing my guestbook.