Cgi error apache

Apache’s CGI mode allows webmaster’s to reduce memory usage. It is the preferred way to run many low traffic websites.

But the CGI mode is pretty sensitive to things such as permissions and file encoding, that leads to 500 Internal Server Error.

In our role as Support Engineers for web hosts, we’ve seen a wide range of causes for this error.

Some common causes and their fixes are:

• Wrong file or folder permissions – Script files and directories must have EXACTLY 755 permissions. In some servers, directories may need 750 permissions.
• Wrong ownership (user & group issues) – The ownership of the file should be set to “USER : ApacheUser” or “USER : USER” depending on Apache’s configuration.
• Incorrect encoding – Files uploaded in Binary mode will fail execution, and should be re-uploaded as ASCII.

Almost 80% of error 500 issues would be solved by these fixes.

This article is about the rest 20% of causes which are hard to find and fix.

Uncommon causes for Apache CGI Internal Server Error

500 Internal Server Error is a web server’s way of saying, “Something has gone wrong when I tried to display the page. Not sure what.”

If it is not permission or ownership issues, it could be anything from application bugs & Apache misconfigurations to firewall blocks & file system errors.

Here are the top 10 uncommon issues we’ve seen in our course of work.

1. Missing modules

Web applications rely on a lot of PHP or Perl “modules” for specific functions.

Some such modules are part of a standard server setup, but many are not.

We’ve seen that after a migration or a during a new website setup, scripts often fail because all required modules are not present.

The error log will say there are “undefined” functions or “methods” do not exist.

To fix this, we go through the app requirement specifications, and install all missing modules.

2. Network timeouts (of API calls, remote scripts, etc.)

Some web apps get data from remote servers (eg. weather data).

If for some reason this connection to the remote server is interrupted, the web app will wait for a while and then show a time-out error.

Apache then reports this status as an Error 500.

This issue can be hard to troubleshoot as it might not leave a log entry.

We detect timeout issues by inspecting long pending outgoing connections, and fix it by disabling the app feature that requires the outbound connections.

3. Old program (compiler) paths

The first line in every CGI app (called Shebang) contains the path to the program that’s supposed to execute it.

For eg. Perl scripts have this path:

#!/usr/bin/perl

But this path can differ based on operating system vendors, and custom compilation settings.

So, the script will look for the program file in a particular location, and if it’s not found there, the script will show an Error 500.

Two effective methods are:

• Use the paths defined in the server environment – The paths of all programs are stored in the server’s “environment” variable. So, we change the first line by calling the environment, like so:
  • #!/usr/bin/env perl
  • This will make sure that no matter where Perl is setup, the path will be available to the script.
• Define the program paths in Apache config – Use the “AddHandler” and “Action” directives of Apache to execute all files with the right program. For eg. here’s how to setup PHP as a CGI:
  • AddHandler application/x-httpd-php5 php
  • Action application/x-httpd-php5 /local-bin/php-cgi

4. Errors in application code

Website owners can make small errors like deleting a “;” or inserting a stray character while editing application or configuration files.

This will result in the application failing to execute, but Apache will only spit out the cryptic “Internal Server Error” message.

We detect such issues by analyzing the log files, and resolve it by either fixing the code error, or by disabling the plugin / addon / theme that’s causing the error.

5. Old config files with wrong module paths

Websites are often customized for the server’s environment and program paths.

When sites are migrated, their configuration files will contain these old paths which might not be compatible with the new server.

We’ve seen cases where web applications use custom configuration files (say php.ini) to load library functions. This will fail when the path changes in a new server.

In such cases we remove the hard-coded program paths and instead use environment variables to automatically acquire program locations.

6. Security restrictions (Web application firewall, SELinux, etc.)

Most servers these days have Web Application Firewalls such as mod_security or ComodoWAF.

These firewalls can cause an Error 500 if it interprets a page request as an attack.

For eg. we’ve seen web apps failing because an external file calls were interpreted as a Remote File Inclusion attack by mod_security.

In such cases, we create custom firewall exclusion rules so that the app will no longer be blocked, while the server security is not affected.

Changing SELinux setting from “Enforcing” to “Permissive” has also helped us fix this error.

7. No Exec (no execution) restriction on the partition

CGI apps are executed as programs.

For that it needs something called an “Execute” privilege.

This “Execute” privilege is turned off for public accessible partitions such as “/tmp” and data-store partitions such as “/backup” to prevent malware execution.

We’ve seen cases where this “Execute” bit is turned off for website homes, thereby causing the script execution to fail.

We restore exec by:

• # mount -o remount,exec /home

8. Apache & .htaccess misconfiguration (no ExecCGI, no AllowOverride, etc.)

Apache needs to know which directories contain CGI scripts.

That is denoted using the directive “ExecCGI”.

For eg. to denote /cgi-bin/ as a CGI directory, Apache should be configured with:

<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>

In some servers we’ve seen “ExecCGI” disabled in cgi-bin due to misconfiguration in either Apache conf file or an .htaccess in the parent directory.

Similarly, we’ve seen CGI related directives in .htaccess becoming ineffective because .htaccess was not enabled through an “AllowOverride” directive in Apache config.

All this can result in a failed script execution, and consequently an Error 500.

9. Wrong permissions on home directory

CGI directories are usually placed within the home directory. For eg. the path to a cgi-bin in cPanel servers is:

/home/username/public_html/cgi-bin/

Many webmasters take care to change the permission of the cgi-bin directory and the web application directories to 755, but forget to check the home directory’s permissions.

In some Apache configurations (eg. when using SuExec), the home directory should also have 755 permissions. Anything other than that (eg. 777), will cause the script execution to fail.

So, one of the first things we check along with script file permissions is to check the permissions of all directories in the file’s path.

We set all of it just right to make sure the script executes without errors.

10. Chroot related errors that breaks file path

In some shared servers, security is enforced by confining each user to a jailed environment.

This prevents one user from accessing the files of any other user.

But such environments can break softlinks to program files.

For eg. if programs are stored in “/opt/php/bin/” and it is linked to from “/usr/bin/php/”, those references can get broken.

These are pretty rare cases, and we fix it by re-configuring the server (or site) to use the right path instead of softlinks.

Conclusion

Incorrect permission and ownership settings are the biggest causes for Apache CGI Internal Server Errors. But, there are more issues that can cause this error. Today we’ve covered the top 10 uncommon causes for this error as seen by our Support Engineers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

If you try to use a CGI script on your web page and you get an Internal Server Error 500, this means that the CGI script did not execute properly. There are several causes that can generate this error, so a few things will need to be checked.

STEP 1: Check Permissions and Group Ownership

To start, you’ll want to check the /var/log/httpd/suexec_log. The log contains any errors that would result from not having correct permissions set on the file.

The file needs to be in a cgi-bin and must have the owner/group as the username who owns the site. If it’s owned be anyone else, it will not run. Also, the script must have execute permission.

The most common chmod permission is 755 (or rwxr-xr-x). You’ll need to go through all your directories from the public_html down to the directory the script is in, making sure that all permissions are set to 755 (*Note: public_html can be 750 *only* if it has a group of apache).

If Using a Hivelocity Server (Special Requirements)

If you’re one of our customers and you’re experiencing an Internal Server Error 500 on your CGI scripts, then it might be due to missing requirements specific to our servers. The Apache Server software that we run on our Hivelocity web servers has certain group ownership and permissions requirements for CGI scripts. 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.
• CGI script must not have the setuid bit set.
• You must call SSI execs by their full pathname. For example, if you are running a UNIX command located on the web server it would look something like this:

  If you are running a script that is in your pcgi-bin, it might look something like this for corp-web customers:

  and like this for cheap-web and personal web customers:

• The target userid may not be < 100 and the target gid may not be < 20. This rule only affects staffers’ CGI scripts. Staffers must chgrp their scripts to group users or some other group.
• The minimum permissions for CGI scripts is mode 500. For CGI compiled programs, the minimum permissions is mode 100. You can of course grant more permissions if you wish.
• The minimum permissions for server-parsed-html (.shtml) files is mode 004 (readable by other), and exec files included therein must be at least mode 700 for scripts and mode 500 for binaries.

STEP 2: Troubleshooting your CGI Script

If you’ve checked the suexec_log and it only shows the script being run, then it might not be an issue with permissions. The cause of the error may be within the script code itself.

The easiest way to figure out script coding problems is to first run the script manually from an ssh prompt. You can do that using a variation of the following commands:

cd /home/username/domains/domain.com/public_html/cgi-bin

./script.cgi

One common error is the use of an incorrect interpreter. The two most common interpreters are:

#!/usr/bin/perl

and

#!/usr/local/bin/php

This code must appear on the first line of the script.

Sometimes, a file is uploaded in Windows format causing the trailing newline (return) character to form incorrectly. In this instance, the file would need to be re-uploaded in a different format.

Another error that could be generated when running the script manually from ssh would be missing perl modules. If you’re missing perl modules, you’ll need to install them manually. Using CPAN (The Comprehensive Perl Archive Network) is the easiest method to install new perl modules. This can be done with the following command:

eg: perl -e shell -MCPAN install Bundle::DBD::mysql

Popular Links

Looking for more information on CGI Scripts? Search our Knowledge Base!

Interested in more articles about Coding? Navigate to our Categories page using the bar on the left or check out these popular articles:

• PHP as an Apache Module
• How to Install Zend Optimizer on Your Server
• How to Install PIP on CentOS 7

Popular tags within this category include: CGI Scripts, Zend Optimizer, PIP, Python, and more.

Don’t see what you’re looking for? Use the search bar at the top to search our entire Knowledge Base.

The Hivelocity Difference

Seeking a better Dedicated Server solution? In the market for Private Cloud or Colocation services? Check out Hivelocity’s extensive list of products for great deals and offers.

With best-in-class customer service, affordable pricing, a wide-range of fully-customizable options, and a network like no other, Hivelocity is the hosting solution you’ve been waiting for.

Unsure which of our services is best for your particular needs? Call or live chat with one of our sales agents today and see the difference Hivelocity can make for you.

If you have any further issues, questions, or would like some assistance checking on this or anything else, please reach out to us from your my.hivelocity.net account and provide your server credentials within the encrypted field for the best possible security and support.

If you are unable to reach your my.hivelocity.net account or if you are on the go, please reach out from your valid my.hivelocity.net account email to us here at: support@hivelocity.net. We are also available to you through our phone and live chat system 24/7/365.

I am running Apache/2.4.10 (Ubuntu) and I was trying to run CGI scripts with the following configurations.

/etc/apache2/apache2.conf

With the following

Mutex file:${APACHE_LOCK_DIR} default
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
Include ports.conf
<Directory />
    Options FollowSymLinks
    AllowOverride None
    Require all denied
</Directory>

<Directory /usr/share>
    AllowOverride None
    Require all granted
</Directory>

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

AccessFileName .htaccess

<FilesMatch "^.ht">
    Require all denied
</FilesMatch>

LogFormat "%v:%p %h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" vhost_combined
LogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%h %l %u %t "%r" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

###################################################################
#########     Adding capaility to run CGI-scripts #################
ServerName localhost
ScriptAlias /cgi-bin/ /var/www/cgi-bin/
Options +ExecCGI
AddHandler cgi-script .cgi .pl .py

And the /etc/apache2/conf-available/serve-cgi-bin.conf

<IfModule mod_alias.c>
    <IfModule mod_cgi.c>
        Define ENABLE_USR_LIB_CGI_BIN
    </IfModule>

    <IfModule mod_cgid.c>
        Define ENABLE_USR_LIB_CGI_BIN
    </IfModule>

    <IfDefine ENABLE_USR_LIB_CGI_BIN>
        #ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        #<Directory "/usr/lib/cgi-bin">
        #   AllowOverride None
        #   Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        #   Require all granted
        #</Directory>

        ## cgi-bin config
        ScriptAlias /cgi-bin/ /var/www/cgi-bin/
            <Directory "/var/www/cgi-bin/">
                AllowOverride None
                Options +ExecCGI 
            </Directory>

    </IfDefine>
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

I have my cgi-script in the directory /var/www/cgi-bin

with the contents in hello.py and made it executable.

#!/usr/bin/env python

import cgitb
    cgitb.enable()    print("Content-Type: text/html;charset=utf-8")

print "Content-type:text/htmlrnrn"
print '<html>'
print '<head>'
print '<title>Hello Word - First CGI Program</title>'
print '</head>'
print '<body>'
print '<h2>Hello Word! This is my first CGI program</h2>'
print '</body>'
print '</html>'

I also did sudo a2enmod cgi as suggested here Apache2.4.7 on Ubuntu 14.04 won’t execute Python cgi file. The site displays python code instead

When I try to run the script by going to http://localhost/cgi-bin/hello.py I am getting a 500 Internal Server error.

Any help would be greatly appreciated! Thanks

I am trying to set up a server for the «cgit» web-ui for GIT. I have downloaded the source code from the developer’s website and correctly compiled it per the instructions.

My default-server.conf looks like this:

#
# Global configuration that will be applicable for all virtual hosts, unless
# deleted here, or overriden elswhere.
# 

DocumentRoot "/srv/www/htdocs/cgit"

#
# Configure the DocumentRoot
#
<Directory "/srv/www/htdocs">
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs-2.2/mod/core.html#options
    # for more information.
    Options None
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    AllowOverride None
    # Controls who can get stuff from this server.
    Order allow,deny
    Allow from all
</Directory>

<Directory "/srv/www/htdocs/cgit/">
    AllowOverride None
    Options FollowSymlinks +ExecCGI
    DirectoryIndex /
    Order allow,deny
    Allow from all
</Directory>

# Aliases: aliases can be added as needed (with no limit). The format is 
# Alias fakename realname
#
# Note that if you include a trailing / on fakename then the server will
# require it to be present in the URL.  So "/icons" isn't aliased in this
# example, only "/icons/".  If the fakename is slash-terminated, then the 
# realname must also be slash terminated, and if the fakename omits the 
# trailing slash, the realname must also omit it.
#
# We include the /icons/ alias for FancyIndexed directory listings.  If you
# do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "/usr/share/apache2/icons/"

<Directory "/usr/share/apache2/icons">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
ScriptAlias /cgi-bin/ "/srv/www/cgi-bin/"

# "/srv/www/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "/srv/www/cgi-bin">
    AllowOverride None
    Options +ExecCGI -Includes
    Order allow,deny
    Allow from all
</Directory>

# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.
#
# To disable it, simply remove userdir from the list of modules in APACHE_MODULES 
# in /etc/sysconfig/apache2.
#
<IfModule mod_userdir.c>
    # Note that the name of the user directory ("public_html") cannot simply be
    # changed here, since it is a compile time setting. The apache package
    # would have to be rebuilt. You could work around by deleting
    # /usr/sbin/suexec, but then all scripts from the directories would be
    # executed with the UID of the webserver.
    UserDir public_html
    # The actual configuration of the directory is in
    # /etc/apache2/mod_userdir.conf.
    Include /etc/apache2/mod_userdir.conf
    # You can, however, change the ~ if you find it awkward, by mapping e.g.
    # http://www.example.com/users/karl-heinz/ --> /home/karl-heinz/public_html/ 
    #AliasMatch ^/users/([a-zA-Z0-9-_.]*)/?(.*) /home/$1/public_html/$2
</IfModule>


# Include all *.conf files from /etc/apache2/conf.d/.
#
# This is mostly meant as a place for other RPM packages to drop in their
# configuration snippet.
#
# You can comment this out here if you want those bits include only in a
# certain virtual host, but not here.
#
Include /etc/apache2/conf.d/*.conf

# The manual... if it is installed ('?' means it won't complain)
Include /etc/apache2/conf.d/apache2-manual?conf

When I try to access the gui by writing «localhost» in the URL bar in the browser I get a «Server Error — Error 500».

In the error log (/var/log/apache2/error_log) i see this line every time i refresh:

[Mon Apr 23 13:52:39 2012] [error] [client ::1] Request exceeded the limit of 10 subrequest nesting levels due to probable confguration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

I have tried using the LimitInternalRecursion directive, and setting it up to «500» to no end. There is no actual problem with the directive, just some kind of infinite loop of rewrites as far as I can tell.