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. - If, instead of error messages, you see such lines as:
- 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.
Last Modified:Thursday, 14-Apr-2022 11:01:42 EDT
© Copyright 2006-2021
Public Access Networks Corporation