Apache server troubleshooting

With the popularization of network technology, application and continuous improvement of web technology, web services have become one of the important forms of services on the Internet. The original Client/Server mode is gradually replaced by the Browser/Server mode. This article focuses on Apache server troubleshooting skills.

1. Check for configuration file errors

The configuration file of the Apache server is located in the/etc/httpd/CONF/directory. Traditionally, three configuration files are used: httpd. conf, access. conf and SRM. conf to configure the behavior of the Apache server. In the new version of Apache, all the settings are placed in httpd. conf, so you only need to adjust the settings in this file. Among them, 99% Apache server error is caused by a configuration file error.

1. Use the apachectl configtest command

If the configuration file is incorrect, run the apachectl configtest command. The apachectl configtest command can check all syntax errors and logical errors.

Instance 1

The following is a sample configuration file:

<Location/Server-status> sethandler server-statusorder deny, allowdeny from allallow from 192.168.149. </location>

If the error code in the blacklist is "<location/Server-status", write less than one.
The apachectl configtest command will check this problem and output the following:

Apachectl configtestsyntax error on line 918 of/etc/httpd/CONF/httpd. conf: <location> directive missing closing '>'

2. Use Service Management Tools

If the configuration file is incorrect, you can use the GUI tool to view it. The following figure shows instance 1 in "service configuration" of the GUI tool.

Figure 1 check for errors using GUI tools

2. Learn to use error logs An error log is the most important log file. Its file name and location depend on the errorlog command. Apache httpd stores diagnostic information and errors in processing requests in this file. Because the error details and solutions are often included, if the server is started or running, first, check the error log. The error log is your friend. Any error is recorded in the error log, so you should first check it. If your website space provider does not allow access to error logs, you should consider changing the Space Provider. Learn to read error logs to quickly locate and solve problems. 1. Error Log format The default error log configuration for Apache is as follows: Errorlog logs/error_log Loglevel warn Configuration error logs are relatively simple. You only need to describe the log file storage path and log record level. Format: Date and time error level error message 2 log record level The following describes the log record levels, including eight levels. Level 1 English name (emerg): the system becomes unavailable in case of an emergency, such as system downtime. Level 2 alert English name, which requires immediate attention Level 3 English name crit, warning of dangerous situations Level 4 English name error, except for emerg, alert, and crit errors Level 5 English name warn. Warning Information 6 levels of English name notice, need to pay attention to the situation, but not as important as error, warn Level 7 English name info, a common message worth reporting 8-level English name debug, messages generated by programs running in debug mode Example of an error log file The error log format is relatively flexible and can be appended with text descriptions. Some information may appear in the vast majority of records. A typical example is: [Wed Oct 11 14:32:52 2007] [Error] [client 127.0.0.1] client denied by server configuration:/export/home/live/AP/htdocs/test The first is the date and time when the error occurred. The second is the severity of the error. The loglevel Command records only errors higher than the specified severity level; the third option is the IP address that causes the error. Later, the information itself. In this example, the server rejects the access from this customer. When the server records the accessed files, it uses the file system path instead of the web path. The error log contains multiple types of information similar to the preceding example. In addition, any information output to stderr in the CGI script is recorded as debugging information in the error log. You can add or delete error log items. However, for some special requests, there will also be corresponding records in the access log. For example, in the above example, there will also be corresponding records in the access log, whose status code is 403, because access logs can also be customized, you can get more information about error events from access logs. Understand error codes and prompts The common error response code is as follows: 301: inform the user that the requested URL has been permanently moved to the new URL. You can remember the new URL so that you can directly use the new URL for access in the future. 302: notifies the user that the requested URL is temporarily moved to the new URL. the user does not need to remember the new URL. If the error response code is omitted, this value is used by default. 303: inform the user that the page has been replaced. The user should remember the new URL. 401: Authorization failed, that is, the password is incorrect. 403: Access denied access error, that is, the file cannot be read. 404: The file not found cannot be found. 410: indicates that the page requested by the user no longer exists. You should not use the redirected URL parameter when using this code. 500: internal server error. It may be because the Web server itself has a problem or a program written has an error. Error Message description "Invalid argument: core_output_filter: writing data to the network" Message Apache may use the system to call sendfile on a platform to accelerate response sending. Unfortunately, in some systems, Apache will detect the existence of sendfile during compilation, even if it cannot work properly. This often happens when a network or other non-standard file system is used. Symptoms of this problem include the above information appearing in the error log and sending a zero-length response to a non-zero-length file request. Generally, this problem occurs only on static files, because dynamic files usually do not use sendfile. To fix this problem, use the enablesendfile command to disable sendfile usage for all the servers. See the enablemmap command to solve similar problems. "Premature end of script headers" Message Most CGI script problems that cause this error will send an "internal server error" error message to the browser. "Permission denied" Message The "Permission denied" error in error_log is accompanied by a "forbidden" message sent to the client, which usually indicates that the permission of the file system is violated, rather than an error in the Apache HTTP configuration file. Check and confirm that the user and group used to run the sub-process have sufficient permissions to access the file that causes the problem. At the same time, check whether the directory of the file that causes the problem and all its parent directories have the permission to execute (Search) (that is, chmod + x ). Recently released Fedora Core and other Linux releases use SELinux for additional access control. Violation of these restrictions may also lead to "Permission denied" messages. "POST method not allowed" Message This indicates that Apache is not correctly configured to execute the CGI program. Re-read Apache configuration to see what is missing. "Internal server error" Message Check the Apache error log to find the error message "premature end of script headers" generated by the CGI program ". In this regard, you need to check the following items to find out why the correct HTTP header cannot be generated.

3. Continuous monitoring of error logs

You can run the "tail-F error_log" command to continuously monitor any problems. To understand what happened on the server, you must check the log file. Although the log file only records events that have occurred, it will let you know the attacks on the server and help you determine whether it has reached the necessary security level. Some examples:
Grep-c "/JSP/source. jsp? /Jsp // JSP/source. jsp ?? "Access_loggrep" client denied "error_log | tail-N 10

The previous meeting will list the number of attacks that attempt to use Apache Tomcat source. jsp Malformed Request Information Disclosure Vulnerability. The next meeting will list the last 10 rejected clients:
[Thu Jul 11
17:18:39
2002] [Error] [client foo.bar.com] client denied by server configuration:/usr/local/Apache/htdocs/. htpasswd

It can be seen that the log file only records the events that have occurred. Therefore, if the client can access the. htpasswd file, and the access log contains the following records:
Foo.bar.com-
-[12/JUL/2002: 01: 59: 13
+ 0200] "Get/. htpasswd HTTP/1.1"

This may indicate that the following commands in the server configuration file have been annotated:
<Files ~
"^/. Ht"> order allow, denydeny from all </Files>

4. Check the Apache server module.

If the Apache server can be started, but some functions cannot be implemented, such as the WebDAV function described earlier, the module that provides this function is usually not loaded. In this case, you can run the following command: "httpd-M" to view the module loading status.

It outputs a list of enabled modules, including the modules for static compilation on the server and the modules for dynamic loading as DSO. You can also use a browser to access http: // 192.168.1.12/Server-info /? List to get 2.

Figure 2 module Loading

5. View Apache 2.x information published by red hat.

Perform the following steps to view information about Apache 2.2.3 released by red hat.

(1) view compilation configuration parameters
Use the httpd-V command,
Httpd-vserver version: Apache/2.2.3server built: Nov 29
2006
06: 33: 19server's module magic number: 20051115: 3 server loaded: Apr 1.2.7, APR-util 1.2.7compiled using: Apr 1.2.7, APR-util 1.2.7architecture: 32-bitserver MPM: preforkthreaded: noforked: Yes (variable process count) server compiled .... -D apache_mpm_dir = "server/MPM/prefork"-D APR_HAS_SENDFILE-D APR_HAS_MMAP-D apr_have_ipv6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE-D APR_USE_PTHREAD_SERIALIZE-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT-D APR_HAS_OTHER_CHILD-D AP_HAVE_RELIABLE_PIPED_LOGS-D dynamic_module_limit = 128-d httpd_root = "/etc/httpd"-D suexec_bin = "/usr/sbin/suexec"-D default_pidlog = "logs/httpd. PID "-D default_scoreboard =" logs/apache_runtime_status "-D default_lockfile =" logs/accept. lock "-D default_errorlog =" logs/error_log "-D ap_types_config_file =" CONF/mime. types "-D server_config_file =" CONF/httpd. conf"

From the above output, you can understand the Apache server version and compiled parameters.

(2) view compiled modules

Use the httpd-l command,
Httpd-lcompiled in modules: core. cprefork. chttp_core.cmod_so.c

Note: The compiled module contains mod_so.c, indicating that the current Apache supports dynamic shared objects (DSO). That is, you can use Apache extension (apxs) without re-compiling Apache) compile a third-party module of Apache. The compiled module contains prefork. C, which indicates that Apache published by Red Hat runs in profork MPM mode.

3. Steps for resolving Apache server faults 1. Check the error log! The Apache server will try its best to help you when you encounter problems. In many cases, it provides some details by writing one or more messages to the error log. Sometimes this is enough for you to diagnose and solve problems yourself (such as file permissions or similar issues ). The default location of the error log is/usr/local/apache2/logs/error_log, but check the errorlog command in the configuration file to confirm the exact location of the error log on your server. 2. Check the syntax again. The Apache configuration file is httpd. conf with a length of 80-99% rows. Almost of Apache faults are caused by syntax errors. You can manually check/etc/httpd/CONF/httpd. conf, or enter: http: // 192.168.1.12/Server-info? In a browser? Config to get the current configuration file, 3. Figure 3 current Apache server configuration file Note: The system automatically adds the row number. 3. Check the Apache FAQ! The latest Apache FAQ list is always available from the Apache main site, http://httpd.apache.org/docs/2.2/faq. 4. view the Apache bug Database Most issues reported to the Apache project team are recorded in the bug database. Before you add a new bug, check the existing reports (enabled and disabled ). If you find that your problem has been reported, do not add a report like "Me too. If the original report has not been closed, we recommend that you check it regularly. You can also consider contact with the original submitter, because problems that are not recorded in the database may be found during email communication. 5. Ask a question in a User Forum Apache has an active user community that is willing to share knowledge. Participation in this community is usually the fastest and best way to get answers. Apache user email list: http://httpd.apache.org/userslist.html 6. Submit the problem report to the bug database. If the above steps are not answered, please be sure to let httpd developers understand this problem, here (http://httpd.apache.org/bug_report.html) to submit a bug report. 7. obtain commercial support You can obtain the technical support from the following website: Http://www.apache.org/info/support.cgi 8. Learn more about the network resources of the Apache server. Apache server is the most widely used Web server and has many versions. You can obtain a large number of useful tips from the following network resources to help you quickly resolve faults and establish web services. General Apache documentation: http://httpd.apache.org/docs-2.0 Apache FAQ: http://www.apache.org/foundation/faq.html 1.3 FAQ: http://httpd.apache.org/docs/misc/FAQ.html Mail List: http://httpd.apache.org/userslist.html Red Hat Enterprise Linux 5 deployment guide: Http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/zh-CN/Deployment_Guide/index.html Summary: This article describes how to establish an Apache server in Linux and how to troubleshoot the problem. It should be noted that Apache is attacked by hackers, which is a major cause of Server failure. However, it is not completely comprehensive here, you can read the author of the Linux server security policy details chapter 6 (http://www4.it168.com/jtzt/shenlan/server/linux02/linux02.htm) which describes in detail to improve the Apache server security methods.