The Panix Help System -- Web Page Help

How do I troubleshoot my CGI script?

If you try to use a CGI script on your web page and you get an Internal Server Error, please go through the following steps to troubleshoot the problem.

NB: It is important to keep track of system upgrades; a major upgrade can cause some programs to stop working.
Upgrades are announced well in advance, via MOTDs and in panix.upgrades. We urge everyone to keep track of those announcements and to do thorough testing in the new environment.

Step 1: Check permissions and group ownership

The Apache Server software that we run on our web servers has certain group ownership and permissions requirements for CGI scripts. For more information about permissions in UNIX and how to change them, see the man page for the chmod command. Please check to see that your script meets the following requirements:

The directory the CGI script resides in must not be writable by other or by group users.
The CGI script itself must not be writable by other or by group users.
The CGI script must not have the setuid bit set.
The minimum permissions for CGI scripts is mode 500 and, for CGI compiled programs, mode 100. You can, of course, grant more permission if you wish. For more information about permissions and how to change them, see the man page for the chmod command.
The minimum permissions for server-parsed-html (.shtml) files is mode 004 (readable by other). Exec files included therein must be at least mode 700 for scripts and 500 for binaries. For more information about permissions and how to change them, see the man page for the chmod command. For tips on working with server-side includes at Panix, please see our server-side includes help page.

Step 2: Check your logs

You can get helpful information from your access logs, your error logs, and your cgi logs (if you are using CGI).

error logs

cgi logs

access logs

Locate your error (and cgi, if any) logs by running locate-logs at the command line: locate-logs yourdomainname

If you are running on the shared webservers using the shared error log, you will see this output:

CGI log: /net/w/0/rawlogs/www1/cgi-log

CGI log: /net/w/0/rawlogs/www2/cgi-log

Error log: /net/w/0/rawlogs/www1/error_log

Error log: /net/w/0/rawlogs/www2/error_log

OR you may see

CGI log: /net/w/0/rawlogs/web1/cgi-log

Error log: /net/w/0/rawlogs/web1/error_log

You might also be running on shared webservers with your own error log, which will change the error log to:

Error log: /htdocs/corp-dirs/yourusername/yourdomainname/httpd_logs/error_log

If you are on a dedicated server, you will see your dedicated webserver's name:

CGI log: /net/w/0/rawlogs/dwN/cgi-log

Error log: /net/w/0/rawlogs/dwN/error_log

cgi logs

First, locate your cgi log. Then, check to see if the file exists at that location. If it's not there, you don't have any cgi log entries. Either you are not using CGI or the log has rolled over.

If your cgi log exists, grep for your script name:
grep myscript /net/w/0/rawlogs/[servername]/cgi-log

If the log entry looks something like this, and there is no line after it with an error message:
[2011-03-18 13:30:54]: uid: (123/pweb) gid: (21/panix-home) cmd: counter.cgi
It means that your program ran. If it is exiting for some reason, try putting
print ("Content-type:text/plain\n\n");
at the very beginning of your script. This will let you see any error messages that are currently disappearing in to the void. If you get a blank page instead of an error message, add a whole pile of print statements to try to see how far it gets and where it is dying.
If you are on the shared web logs, please remember that this is a shared server, therefore you will see other people's error messages in the log.
If there is an error message following the log entry like the one above, then it means that the program did not run and it will tell you why. Usually it is a permissions or group ownership problem (see STEP 1 above). Some of the errors you might expect to encounter are:
cannot get current working directory :

cannot stat program :

The webserver cannot suexec to call this program. Are you using exec cmd? If yes, convert to using exec cgi. (See our server side include help page for assistance.)

directory is writable by others :

chmod o-w directoryname

file has no execute permission:

chmod u+x filename

file is writable by others :

chmod o-w filename

error logs

First, locate your error log.
Next,
grep -w $USER /net/w/0/rawlogs/www?/error_log
or
grep -w $USER /net/w/0/rawlogs/dwN/error_log | tail

If, instead of error messages, you see such lines as:
aplog: Opened "/htdocs/myusername/mydomain/httpd_logs/error_log" for site mydomainname.
then you have your own error_log, in your web space.

access logs

NB: your web access logs are compiled hourly. You cannot rapidly debug using them. However, for some kinds of errors, checking HTTP requests can be useful, if slow. Here's how you go about it:

You can retrieve your access logs using getclogs.
getclogs | tail -1
and subtract 1000 from the output for a suitable value (N) to pass with the -s getclogs -s N

Most of our users are running on shared webservers, with web accelerators (squids) serving cached requests. To see which requests are being served through the squids, use the -c option to getclogs:
getclogs -c | tail

See our getclogs help page for assistance understanding your access logs.

Step 3: Run on a non-shared webserver

If you are a single-user (with or without the Cheap web option) on the shared webservers, and you can't find any errors in the logs, but you are getting an Internal Server Error, try visiting the webservers independently. Use www1.panix.com or www2.panix.com explicitly in your URL:
http://www1.panix.com/~yourusername/etc.

Step 4: It still doesn't work; what do I do now?

If you have tried all of these things and you are still having a problem try posting to the newsgroup panix.user.html. There are many panix users and staff members who frequent that group who can help you figure out what is wrong. Please post as much information as you can about the script and any troubleshooting measures you have already taken.