Troubleshooting Guide for Perl and CGI Scripts

Overview

Many users and system administrators frequently encounter issues with CGI and Perl scripts. This troubleshooting guide outlines common problems and provides their respective solutions.

Please note: Since WebPros International, LLC does not develop custom Perl scripts, cPanel Technical Support is unable to assist with issues related to them.

Note: The example.cgi script is used throughout the following examples for troubleshooting purposes.

Troubleshooting Steps

To troubleshoot your CGI and Perl scripts, follow these steps:

Verifying Script Permissions

Verify that the script has the correct execution permissions for relevant users and groups. To inspect a script's permissions, execute the ls -la example.cgi command as the root user.

The output will be similar to the following example:

-rw-rr- 1 burst wheel 41 May 29 16:04 example.cgi

In this example, the script exhibits the following permissions:

• Everyone can read the script.
• Only the owner can write to the script.
• Nobody can execute the script.

To modify the script's permissions, use the following command:

chmod 755 example.cgi

This command grants the script the following permissions:

• Everyone can read and execute the script.
• Only the owner can write to the script.

For further details on file system permissions, refer to Wikipedia’s numeric notation article.

Inspecting Script Code for Errors

If the server continues to return a 500 error, it is likely that a code error exists within the script.

Insert the following code at the beginning of your script:

#!/usr/bin/perl use CGI::Carp qw(fatalsToBrowser);

This modification redirects script errors to the browser, preventing the display of a generic 500 error.

To check for code errors, execute the perl -w ./example.cgi command. This command runs the script with the warnings flag, which will display any errors in the code, similar to the following example:

Can’t find string terminator ‘"’ anywhere before EOF at ./example.cgi line 3.

This message signifies that the Perl script is unable to execute due to fatal errors.

Note: We strongly recommend consulting online tutorials for Perl and guidance on troubleshooting specific error messages.

Adding a Content Type Header

If errors were identified and corrected within the code, re-run the script from the command line using the following command:

perl -w ./example.cgi Hello World !

If the script functions correctly when executed from the command line but fails in a browser, it might not be sending the appropriate content type header to the browser.

For instance, if example.cgi executes successfully in the shell but fails to display in a browser, resolve this by adding the following line near the top of the script:

print “Content-type: text/html

”;

Upon running the updated script with the perl -w ./example.cgi command, you should observe output similar to the following:

Content-type: text/html Hello World !

Sanity Testing Permissions with the suEXEC Module

If the script still fails to work in the browser, even with the correct content type, the suexec module could be the cause. The Apache web server frequently incorporates the suexec module as a security feature. It rigorously tests the permissions of CGI scripts prior to execution, verifying that appropriate users have access.

Once the suexec module completes its checks, it ensures that scripts run with the permissions of the account owner.

To verify proper permissions, execute the ls -la command, which will produce output similar to the following:

1
2
3
4

total 6
drwxr-xr-x 2 burst wheel 512 May 29 16:04 .
drwxr-xr-x 3 burst wheel 512 May 29 16:03 ..
-rwxr-xr-x 1 burst wheel 78 May 29 16:24 example.cgi

The “.” directory denotes the current working directory. Configure this directory with the following permissions:

• Everyone can read and execute the script.
• Only the owner can write to the script.

Should script problems persist, inspect the suexec log file located in the /usr/local/apache/logs/ directory. Use the tail -f suexec_log command to monitor the log file, then attempt to load the script in your browser to identify the error.

Verifying Ownership with the suEXEC Module

Confirm that the file is owned by the account's user. Occasionally, corruption in the password or group file may result in a numeric ID being displayed instead of a username.

When executing the ls -la command with a corrupt file present, the output will resemble the following example:

1
2
3
4

total 6
drwxr-xr-x 2 8840 8840 512 May 29 16:04
. drwxr-xr-x 3 burst wheel 512 May 29 16:03
.. -rwxr-xr-x 1 8840 8840 78 May 29 16:24 example.cgi

To rectify this error, execute the chown burst.burst * * command, where burst denotes the account owner's username. This action will restore the correct ownership for the script and the directory.

Even if the output displays a correct owner name, a different user ID might be returned. This discrepancy would typically be logged in the suexec_log file.

If, after performing all these steps, the script remains non-functional, please submit a support ticket.

Addressing "getgrgid invalid groupid XXXXX" Errors

The following output illustrates an example of an error message from a Perl script found in Apache's error log (/usr/local/apache/logs/error_log):

[Tue Mar 26 09:13:16 2002] [error] [client x.x.x.x] (2)No such file or directory: getgrgid: invalid groupid 32015
[Tue Mar 26 09:13:16 2002] [error] (2)No such file or directory: exec of /home/username/public_html/utility.cgi failed
[Tue Mar 26 09:13:16 2002] [error] [client x.x.x.x] Premature end of script headers: /home/username/public_html/script.cgi

To resolve this error, execute the following command:

/scripts/fixcommonproblems --group

If the issue persists, verify the permissions on the passwd and shadow files.

Should these steps not resolve the problem, please submit a support request.