Apache problems with these Troubleshoot tips -R&D26012012

open source Apache webserver is well-proven, but can still offer an administrator headaches from timeto time when things don't go quite as planned. In this article, I will provideyou with eight tips to help you solve the most common Apache dilemmas.
Tip #1: Know where to look

If you're having trouble with Apache, or seeming to havetrouble with one of its modules, your first stop should be in looking overApache's detailed error log. Depending on how your system and Apache areconfigured, the error log may live in different locations. The default locationfor this file is a file named error_log located in the logs directory insideyour Apache root installation. If you can't find your error log, open thehttpd.conf configuration file and look for the ErrorLog directive, whichdefines the location.

Apache is initially configured to the "warn" loglevel, meaning that any problem more serious than a warning (critical,emergency, error, alert, and warn) is logged. You can adjust the logging levelin httpd.conf my manipulating the LogLevel directive.

From the Apache documentation, Table A outlines the eightavailable warning levels and provides an example of what would be logged atthat level.

If you can't figure out why your Apache server is having aproblem, try adjusting the log level to a higher threshold to capture moreinformation. After you change the level, stop and restart your server.

There are actually two log files in Apache: error_log, whichI described in this section, and access_log. The error_log file, as you mightexpect, is the log of most interest for troubleshooting purposes. However, alsomake use of the access_log when looking for problems. This file lists all ofthe items pulled down by clients along with the HTTP error or success code.
Tip #2: Don't let an AllowOverride ruin your day

Depending on how you want to run your web site, you canselectively alter the behavior of your Apache server by making use of .htaccessfiles. Simply put, an .htaccess file is a file in a directory that lets youmake configuration changes that affect just that folder. For example, if you'vedisabled the "Indexes" in httpd.conf for all directories, none f yourvisitors will be able to access a directory listing. You may have a singlefolder for which this access should be allowed. In this case, you would have an.htaccess file with the "Options Indexes" directive.

You can probably begin to see some reasons that .htaccessfiles can be problematic. First of all, for very large sites, keeping track ofthese files could be a very difficult task. Now, when you have a functionalityproblem, you can't just look to one source for possible configuration problems.You now need to traverse your directory structure and look for .htaccess files.

Second, by allowing the use of these files, you may beallowing users the lack your Apache security prowess to make potentiallyinsecure changes to your web site.

Finally, use of .htaccess can exact a performance penalty onyour web site due to the need of the web server to look for an .htaccess filein the current directory and in every superior directory all the way to thedocument root of the web server.

Unless you have a really good reason, avoid the use of.htaccess files. Instead, in the httpd.conf file, make liberal use of "Directory"sections to set per-directory options.

On the other hand, if you are using .htaccess files and they don't seem to be activated, lookto the httpd.conf file and make sure the directive "AllowOverride" isnot set to "None". You can limit what options are allowed in an.htaccess file by further manipulating the AllowOverride directive's type. Table B, based on the Apache documentation, provides you with a list of possibleAllowOverride options. Only use the options you need.
Tip #3: A newly installed module/extension (such as PHP) is not working

Suppose, for example, that you recently installed the PHP extension,but, upon visiting your site, you're seeing the PHP code itself instead of theresults of that code's execution. First off, for folks new to Linux, installingnew modules and getting everything working perfectly can be akin to setting upa Christmas tree with your hands tied behind your back.

Since it's among the most popular available, let's use thePHP module for an example.

Your problem could be something very simple. Apache may notbe configured to do anything with the .php extension. Look at your httpd.confconfiguration file and look for the DirectoryIndex directive. Make sure theline reads:

DirectoryIndexindex.html index.php

The default Apache installation omits the "Index.php"file, rendering many PHP-based sites useless.

Further, your httpd.conf file needs to tell Apache a littlebit about the .php extension through the use of the AddType directive. If you'reusing PHP, you should have a line in your configuration that reads:

AddTypeapplication/x-httpd-php .php

Normally, this line is commented out.

Finally, make sure your httpd.conf file is actually loadinga supported PHP module. If you're not loading the PHP handling module, Apachewon't know what to do with .php pages, no matter how many AddType directivesyou include. Here is an example LoadModule directory for PHP 4.

(Apache 2+) LoadModulephp4_module modules/libphp4.so

(Apache 1.3) LoadModulephp4_module libexec/libphp4.so

Apache 1.3 also requires a fourth directive:

AddModule mod_php4.c

If this still isn't working, make sure your module iscompatible with the version of Apache you're running. The PHP developers, forexample, recommend that, for Apache 2 and later, you use at least PHP 4.3.0.

The short answer: Make sure you've strictly followed theinstructions for setting up Apache with additional modules. I've highlightedsome of PHP's requirements in this tip, but every module has its own nuances.
Tip #4: Don't worry about "connection reset by peer" errors toomuch… but do watch for it.

When a user cancels a request to your site (presses the Stopbutton or hits Escape), your server logs will be appended with the message "connectionreset by peer". If you see this message only occasionally, it probablymeans someone typed in the wrong address or just got impatient while waitingfor your site to load. If you're seeing this message on a regular basis, youmight have congestion issues slowing your site to a point beyond the toleranceof some people. You may have other network issues creating this problem.
Tip #5: Make sure Apache is actually running

I'm going to 'fess up here… This one has bitten me in thepast. I spent quite some time looking through error logs and the httpd.conffile before I even bothered to make sure Apache was evening running! After severely reprimanding myself, I startedthe service and, until today, have never told a soul.

The point: Any day can be an off day! Look for the simplethings, too.
Tip #6: Use configtest

So you've made some modifications to your httpd.conf fileand now Apache isn't working properly… oh, by the way, you don't have a handybackup of the original file to find out what's wrong.

The god folks that created Apache have provided you with away to scan your httpd.conf file and make sure it's free from obvious errors. Thiserror checking tool is provided as a part of the apachectl program. To use it,execute apachectl -configtest fromthe command line. The apachectl program is located in the bin directory of yourApache installation.

If no errors are found, the utility will execute like thisexample:

[root@localhost bin]#./apachectl configtest

Syntax OK

To show how this tool works, I've intentionally create ahttpd.conf file with an error or two.

[root@localhost bin]#./apachectl configtest

Syntax error on line 22of /usr/local/apache/conf/httpd.conf:

Invalid command 'sserversignature',perhaps misspelled or defined by a module not included in the server configuration

In this case, I have misspelled a directive, which shouldread "ServerSignature", not "SServerSignature". Even if youcorrect the error, run the tool again as more errors may be found. As ahighlight to this, I actually had another error in my httpd.conf file.

[root@localhost bin]#./apachectl configtest

Syntax error on line108 of /usr/local/apache/conf/httpd.conf:

DocumentRoot must be adirectory

In this case, the directory name in the DocumentRootdirective also had a spelling error which would have resulted in Apache beingunable to serve any content since the directory does not exist.

The apachectl program has a number of options, some of whichyou can see in Table C. You've probably used "start" and "stop",but there are many more that maybe useful depending on what you're trying todo.
Tip #7: Know where to find Apache community resources

The Apache community is huge and there are a ton of placesto go for help when you have a problem. In my Apache experience, I've usedTechRepublic and other professional sites, but my first stop is Google. Typethe exact error message or symptom and the chances are really good that you'llget some hits back.

Failing that, here are some other outstanding resources thatyou can use for help:

http://p.webring.com/hub?ring=apachesupport - This is the main page of the Apache support webring that houses a plethora of information about Apache and provides a place to start when trying to solve a difficult problem.
IRC channel #Apache - This is an IRC room with live Apache experts that, if you are patient, are willing to help you through a problem. When using this resource, make sure to understand that these folks do this out of the goodness of their hearts, so be thankful!
http://httpd.apache.org/docs/ - A link to the Apache documentation. It's amazing how many problems can be solved by reading the manual!

Tip #8: Understand the various HTTP/1.1 error codes

Specific HTTP errors on a client or in your server logs canhelp point you in the right direction. For example, if you have userscomplaining that they always get "404" errors when they click a linkto visit your site, the host link is pointing to a page on your Apache serverthat does not exist. Or, if a client receives a "501" error, theclient is attempting to access content on your server for which no handlerexists. Often this error can be the result of a problem with a CGI script.

In Table D, I've taken information (with permission)from the W3C, the organization responsible for keeping HTTP error messagesconsistent, and reformatted it to be a little more easily read and removed from the extraneous information.