Tutorial Series
This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the Apache web server.
Each tutorial in this series includes descriptions of common Apache configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot Apache. Subsequent tutorials examine specific errors in detail.
Tutorial
Updated on July 31, 2020
There are three main commands, and a set of common log locations that you can use to get started troubleshooting Apache errors. Generally when you are troubleshooting Apache, you will use these commands in the order indicated here, and then examine log files for specific diagnostic data.
The commands that you will commonly use to troubleshoot Apache across most Linux distributions are:
systemctl
- Used to control and interact with Linux services via the systemd
service manager.journalctl
- Used to query and view the logs that are generated by systemd
.apachectl
- When troubleshooting, this command is used to check Apache’s configuration.These commands, how to use them, and Apache’s log locations where you can find additional information about errors are described in further detail in the following sections.
Note: On Debian and Ubuntu systems, the Apache service and process name is apache2
, whereas on CentOS, Fedora, and other RedHat-derived systems, Apache’s service and process name is httpd
. Apart from the differences between the service and running process names, starting, stopping, and checking Apache’s status, as well as logs with journalctl
should work the same on any Linux system that uses systemd
to manage the Apache service. Be sure to use the correct name for your Linux distribution.
systemctl
Commands for ApacheTo troubleshoot common Apache errors using the systemd
service manager, the first step is to inspect the state of the Apache processes on your system. The following systemctl
commands will query systemd
for the state of Apache’s processes.
On Ubuntu and Debian systems run:
- sudo systemctl status apache2.service -l --no-pager
The -l
flag will ensure that output is not truncated or ellipsized. The --no-pager
flag will make sure that output will go directly to your terminal without requiring any interaction on your part to view it. You should receive output like this:
Output● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: active (running) since Mon 2020-07-13 14:43:35 UTC; 1 day 4h ago
Process: 929 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 1346 (apache2)
Tasks: 55 (limit: 4702)
CGroup: /system.slice/apache2.service
├─1346 /usr/sbin/apache2 -k start
. . .
To inspect the Apache process on CentOS and Fedora systems run:
- sudo systemctl status httpd.service -l --no-pager
You should receive output like this:
Output● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2020-07-14 19:46:52 UTC; 3s ago
Docs: man:httpd.service(8)
Main PID: 21217 (httpd)
Status: "Started, listening on: port 80"
Tasks: 213 (limit: 2881)
Memory: 16.6M
CGroup: /system.slice/httpd.service
├─21217 /usr/sbin/httpd -DFOREGROUND
. . .
Jul 14 19:46:52 localhost.localdomain httpd[21217]: Server configured, listening on: port 80
In either case, make a note of the Active
line in the output. If your Apache server does not show active (running)
as highlighted in the previous examples but you expect it should, there may be an error. Typically if there is a problem, you will have a line like the following in your output (note the highlighted failed
portion):
Example Error OutputActive: failed (Result: exit-code) since Tue 2020-07-14 20:01:29 UTC; 1s ago
If there is a problem with your Apache process or configuration you can troubleshoot it further using the journalctl
command.
journalctl
Commands for ApacheTo inspect the systemd
logs for Apache, you can use the journalctl
command. The systemd
logs for Apache will usually indicate whether there is a problem with starting or managing the Apache process.
These logs are separate from Apache’s request and error logs. journalctl
displays logs from systemd
that describe the Apache service itself, from startup to shutdown, along with any process errors that may be encountered along the way.
On Ubuntu and Debian systems use the following command to examine the logs:
- sudo journalctl -u apache2.service --since today --no-pager
The --since today
flag will limit the output of the command to log entries beginning at 00:00:00 of the current day only. Using this option will help restrict the volume of log entries that you need to examine when checking for errors. You should receive output like the following:
OutputJul 14 20:12:14 ubuntu2004 systemd[1]: Starting The Apache HTTP Server...
Jul 14 20:12:14 ubuntu2004 systemd[1]: Started The Apache HTTP Server.
If you are using a CentOS or Fedora based system, use this version of the command:
- sudo journalctl -u httpd.service --since today --no-pager
You should receive output like the following:
OutputJul 14 20:13:09 centos8 systemd[1]: Starting The Apache HTTP Server...
. . .
Jul 14 20:13:10 centos8 httpd[21591]: Server configured, listening on: port 80
If there is an error, you will have a line in the output that is similar to the following, with the main difference between Linux distributions being the highlighted yourhostname
portion:
Example Error OutputJul 14 20:13:37 yourhostname systemd[1]: Failed to start The Apache HTTP Server.
If your Apache server has errors in the journalctl
logs like the previous example, then the next step to troubleshoot possible issues is investigating Apache’s configuration using the apachectl
command line tool.
apachectl
Most Linux distributions include the apachectl
utility with Apache. apachectl
is an invaluable tool to help detect and diagnose Apache configuration problems.
To troubleshoot issues using apachectl
, test your Apache configuration using the apachectl configtest
command. The tool will parse your Apache files and detect any errors or missing settings before attempting to start the server.
Run the command like this on Ubuntu, Debian, CentOS, and Fedora based distributions:
- sudo apachectl configtest
A working Apache configuration will result in output like the following:
OutputSyntax OK
Depending on your Linux distribution, there may be other lines mixed in with the output, but the important line is the one that says Syntax OK
.
If there is an error in your Apache configuration, like a directive that references a module that is not enabled or even a single typo, apachectl
will detect it and attempt to notify you about the problem.
For example, attempting to use directives for an Apache module that is not enabled will result in apachectl configtest
messages like the following:
Example Error OutputAH00526: Syntax error on line 232 of /etc/apache2/apache2.conf:
Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
In this example the ssl
module is not enabled, so the SSLEngine
directive generates an error when the configuration is tested. The last line also indicates that The Apache error log may have more information
, which is the next place to look for more detailed debugging information.
Apache log files are a very helpful resource for troubleshooting. Generally, any error that you receive in a browser or other HTTP client will have a corresponding entry in Apache’s logs. Sometimes Apache will also output errors related to configuration, built-in modules, and other debugging information to its log files.
To examine log files for errors while troubleshooting Apache on a Fedora, CentOS, or RedHat server, examine the /var/log/httpd/error_log
file.
If you are troubleshooting a Debian or Ubuntu derived system, examine /var/log/apache2/error.log
for errors using a tool like tail
or less
. For example, to view the last two lines of the error log using tail
, run the following command:
- sudo tail -n 2 /var/log/apache2/error.log
Substitute the number of lines that you would like to examine in place of the number 2
in the command. On a CentOS or Fedora system, the log file to examine is /var/log/httpd/error_log
.
An example error will resemble something like the following lines, regardless of which Linux distribution you are using to run your Apache server:
Error Log Examples[Wed Jul 15 01:34:12.093005 2020] [proxy:error] [pid 13949:tid 140150453516032] (13)Permission denied: AH00957: HTTP: attempt to connect to 127.0.0.1:9090 (127.0.0.1) failed
[Wed Jul 15 01:34:12.093078 2020] [proxy_http:error] [pid 13949:tid 140150453516032] [client 127.0.0.1:42480] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
The two lines in this output are distinct error messages. They both reference the module causing the error (proxy
in the first line, proxy_http
in the second) and include an error code that is specific to the module. The first one, AH00957
, indicates that the Apache server attempted to connect to a backend server (127.0.0.1 on port 9090 in this case) using the proxy
module but failed to do so.
The second error is derived from the first: AH01114 is a proxy_http
module error that also indicates that Apache was unable to connect to the configured backend server to make an HTTP request.
These example lines are just for illustration purposes. If you are diagnosing errors with your Apache server, chances are the error lines in your logs will have different contents than these. Regardless of your Linux distribution, the format of any error lines in your logs will include the relevant Apache module and error code, as well as a text description of the error.
Once you have an idea of what might be causing problems with your Apache server you can continue researching and troubleshooting the issue. The error code and text description are especially useful, since they give you explicit and specific terms that you can use to narrow down the range of possible causes of a problem.
Troubleshooting Apache errors can range from diagnosing errors with the service itself, to locating misconfigured options for modules, or to examining customized access control rules in detail. This introduction to diagnosing issues with Apache explained how to use a number of utilities to help narrow down the possible causes of errors. Usually, you will use these utilities in the same order, although you can always skip some, or start directly with examining logs if you have a general idea of what the problem might be.
However, as a general sequence for troubleshooting, it helps to be methodical and use these tools in the order described. Start troubleshooting with systemctl
to examine the state of the Apache server. If you need more information, examine the systemd
logs for Apache using the journalctl
command. If the issue is still not apparent after checking journalctl
, testing Apache’s configuration using apachectl configtest
is the next step. Finally, for in-depth troubleshooting, examining Apache’s log files will usually indicate a specific error, with helpful diagnostic messages and error codes.
The rest of the tutorials in this series will examine some common errors that you may encounter when using Apache in more detail.
Tutorial
Updated on July 31, 2020
An Apache AH00526: Syntax error
message occurs when there is a typo or misconfigured setting somewhere in your Apache configuration files. It is a generic error that can be indicative of a number of underlying problems.
The error can be detected using apachectl configtest
before an invalid configuration is loaded. It can also be found using the systemctl
and journalctl
commands. In the latter two cases, Apache will be unable to run because of the error.
If you have detected the error using apachectl
then skip to the Troubleshooting Using the Built in apachectl
Command section of this tutorial. Otherwise, the next section will explain how to use systemctl
to troubleshoot the error.
systemctl
Following the troubleshooting steps from the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series, the first step when you are troubleshooting an AH00526 error is to check Apache’s status with systemctl
. It is important to understand if the error affects the running process, or if it is preventing Apache from starting up.
On Ubuntu and Debian derived Linux distributions, run the following to check Apache’s status:
- sudo systemctl status apache2.service -l --no-pager
On CentOS and Fedora systems, use this command to examine Apache’s status:
- sudo systemctl status httpd.service -l --no-pager
The -l
flag will ensure that systemctl
outputs the entire contents of a line, instead of substituting in ellipses (…
) for long lines. The --no-pager
flag will output the entire log to your screen without invoking a tool like less
that only shows a screen of content at a time.
Since you are troubleshooting an AH00526: Syntax error
message, you should receive output that is similar to the following:
Output● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: failed (Result: exit-code) since Wed 2020-07-15 13:45:49 UTC; 1min 37s ago
. . .
Jul 15 13:45:49 f17f01056c5b systemd[1]: Starting The Apache HTTP Server...
Jul 15 13:45:49 f17f01056c5b apachectl[15860]: AH00526: Syntax error on line 2 of /etc/apache2/sites-enabled/000-default.conf:
Jul 15 13:45:49 f17f01056c5b apachectl[15860]: Invalid command 'SSSLCertificateFile', perhaps misspelled or defined by a module not included in the server configuration
Jul 15 13:45:49 f17f01056c5b apachectl[15860]: Action 'start' failed.
Jul 15 13:45:49 f17f01056c5b apachectl[15860]: The Apache error log may have more information.
Jul 15 13:45:49 f17f01056c5b systemd[1]: apache2.service: Control process exited, code=exited status=1
Jul 15 13:45:49 f17f01056c5b systemd[1]: apache2.service: Failed with result 'exit-code'.
Jul 15 13:45:49 f17f01056c5b systemd[1]: Failed to start The Apache HTTP Server.
In this case, Apache is not running because of the syntax error. The error is caused by an extra S character at the beginning of the SSSLCertificateFile
line in the /etc/apache2/sites-enabled/000-default.conf
file. The correct directive should be SSLCertificateFile
, so editing the file to fix the directive name in this example would resolve the error and allow Apache to start.
The systemctl
output in this example also includes some lines from the systemd
journal. If your output indicates a specific line in your configuration file is generating the syntax error, you can skip the journalctl
and apachectl configtest
troubleshooting steps. Instead, you can go directly to the file to inspect and edit the erroneous line to resolve the error.
If your output does not give specific information about the error location in Apache’s configuration files, you will need to examine journalctl
output from the systemd
logs. The following section explains how to use journalctl
to troubleshoot an AH00526 error.
journalctl
logsIf your systemctl
output does not include specifics about an AH00526 syntax error, you can proceed with using the journalctl
command to examine systemd
logs for Apache.
On Ubuntu and Debian-derived systems, run the following command:
- sudo journalctl -u apache2.service --since today --no-pager
On CentOS, Fedora, and RedHat-derived systems, use this command to inspect the logs:
- sudo journalctl -u httpd.service --since today --no-pager
The --since today
flag will limit the output of the command to log entries beginning at 00:00:00 of the current day only. Using this option will help restrict the volume of log entries that you need to examine when checking for errors.
If you have an AH00526 error in your Apache configuration, look through the journalctl
command output for lines like the following:
Output-- Logs begin at Tue 2019-11-05 21:26:44 UTC, end at Tue 2020-06-09 15:13:01 UTC. --
. . .
Jun 09 15:12:28 f17f01056c5b apachectl[3157]: AH00526: Syntax error on line 3 of /etc/apache2/sites-enabled/000-default.conf:
Jun 09 15:12:28 f17f01056c5b apachectl[3157]: Invalid command 'SSLCertificateFile', perhaps misspelled or defined by a module not included in the server configuration
. . .
The first line of output is the AH00526 error. Since this error is a general error related to an invalid setting or a typo in a configuration file, the next line explains what caused the error. In this case it is a directive called SSLCertificateFile
, which will only be valid if the ssl
module is enabled.
If you encounter an AH00526 error that is related to an invalid SSLCertificateFile
directive, you can resolve it by enabling the ssl
module and then restarting Apache to make the error go away.
For Ubuntu and Debian systems, run the following to enable the module:
- sudo a2enmod ssl
- sudo systemctl restart apache2.service
On CentOS and Fedora systems, ensure that the mod_ssl
package is installed, and then load the module by adding it to Apache’s /etc/httpd/conf.modules.d
directory in a file like this:
- sudo yum install mod_ssl
- echo "LoadModule ssl_module modules/mod_ssl.so" | sudo tee > /etc/httpd/conf.modules.d/00-ssl.conf
- sudo systemctl restart httpd.service
Once the module is referenced by Apache and you restart it using the command that is appropriate to your Linux distribution, the server will start up if there are no more errors in the configuration.
However, if there are more errors, Apache and systemctl status
will continue to report them and attempt to explain why the server cannot be started. systemctl
will output failure messages like this on Ubuntu and Debian systems:
Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details
And on CentOS, Fedora, and RedHat derived systems, a failed startup message will be similar to the following:
Job for httpd.service failed because the control process exited with error code.
See "systemctl status httpd.service" and "journalctl -xe" for details.
When Apache will still not start because of errors, using the apachectl configtest
command can be the most efficient and effective way to diagnose issues. The next section will explain how to use the utility to resolve an AH00526 error that is again related to an invalid SSLCertificateFile
directive.
apachectl
To troubleshoot an AH00526 error with Apache’s apachectl
utility, you can test your Apache configuration using the configtest
sub-command. This tool will parse your Apache files to determine whether it’s valid and, if not, locate incorrect settings in the Apache configuration.
The apachectl configtest
command is useful for catching syntax errors before reloading apache with a new configuration. This test can help you to avoid service outages in the event of a misconfigured setting in your Apache files.
The following example configuration test command will return an AH00526 Syntax error
message, and explains that the likely problem is that Apache is referencing an empty SSLCertificateFile
:
- sudo apachectl configtest
OutputAH00526: Syntax error on line 3 of /etc/apache2/sites-enabled/000-default.conf:
SSLCertificateFile: file '/etc/ssl/certs/example.com.pem' does not exist or is empty
In this example output, the /etc/ssl/certs/example.com.pem
file does not exist as the error message notes. Adding an SSL/TLS certificate to the file, or removing the directive will resolve the issue.
A successful apachectl configtest
invocation should result in output like this:
OutputSyntax OK
In this tutorial you learned how to troubleshoot an Apache AH00526 syntax error. The first step when investigating any Apache error is to examine the server’s status with systemctl status apache2
, or systemctl status httpd
depending on your Linux distribution. From there, you can determine whether Apache is running correctly, or if it is unable to start because of the error.
After you have determined Apache’s status, you can diagnose it further using journalctl
to examine the systemd
logs for the process. You can also use the apachectl configtest
command to check the configuration files for errors directly.
Tutorial
Updated on July 31, 2020
An Apache AH00072: make_sock: could not bind to address
error message is generated when there is another process listening on the same port that Apache is configured to use. Typically the port will be the standard port 80
for HTTP connections, or port 443
for HTTPS connections. However, any port conflict with another process can cause an AH00072 error.
The error is derived from the underlying operating system system’s network stack. The issue is that only a single process can be bound to a port at any given time. If another web server like Nginx is configured to listen on port 80
and it is running, then Apache will not be able to claim the port for itself.
To detect a port conflict with Apache, you will need to examine systemctl
and journalctl
output to determine the IP address and port that are causing the error. Then you can decide how to resolve the issue, whether it is by switching web servers, changing the IP address that Apache uses, the port, or any combination of these options.
systemctl
Following the troubleshooting steps from the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series, the first step when you are troubleshooting an AH00072: make_sock: could not bind to address
error message is to check Apache’s status with systemctl
.
If systemctl
does not include output that describes the problem, then the last section of this tutorial, Troubleshooting Using journalctl
Logs explains how to examine the systemd
logs to find the conflicting port.
The output from systemctl status
will in many cases contain all the diagnostic information that you need to resolve the error. It will include the IP address that Apache is using, as well as the port that it is attempting to bind to. The output will also indicate how long Apache has been unable to start so that you can determine how long the issue has been affecting Apache.
On Ubuntu and Debian-derived Linux distributions, run the following to check Apache’s status:
- sudo systemctl status apache2.service -l --no-pager
On CentOS and Fedora systems, use this command to examine Apache’s status:
- sudo systemctl status httpd.service -l --no-pager
The -l
flag will ensure that systemctl
outputs the entire contents of a line, instead of substituting in ellipses (…
) for long lines. The --no-pager
flag will output the entire log to your screen without invoking a tool like less
that only shows a screen of content at a time.
Since you are troubleshooting an AH00072: make_sock
error message, you should receive output that is similar to the following:
Output● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2020-07-28 13:58:40 UTC; 8s ago
Docs: man:httpd.service(8)
Process: 69 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Main PID: 69 (code=exited, status=1/FAILURE)
Status: "Reading configuration..."
Tasks: 213 (limit: 205060)
Memory: 25.9M
CGroup: /system.slice/containerd.service/system.slice/httpd.service
Jul 28 13:58:40 e3633cbfc65e systemd[1]: Starting The Apache HTTP Server…
Jul 28 13:58:40 e3633cbfc65e httpd[69]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Jul 28 13:58:40 e3633cbfc65e httpd[69]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jul 28 13:58:40 e3633cbfc65e httpd[69]: no listening sockets available, shutting down
Jul 28 13:58:40 e3633cbfc65e httpd[69]: AH00015: Unable to open logs
Jul 28 13:58:40 e3633cbfc65e systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
Jul 28 13:58:40 e3633cbfc65e systemd[1]: httpd.service: Failed with result 'exit-code'.
Jul 28 13:58:40 e3633cbfc65e systemd[1]: Failed to start The Apache HTTP Server.
Note that your output may be slightly different if you are using an Ubuntu or Debian-derived distribution, where the name of the Apache process is not httpd
but is apache2
.
This example systemctl
output includes some highlighted lines from the systemd
journal that describes the AH00072 error. These lines, both of which begin with (98)Address already in use: AH00072: make_sock: could not bind to address
, give you all the information about the AH00072 error that you need to troubleshoot it further, so you can skip the following journalctl
steps and instead proceed to the Troubleshooting with ss
and ps
Utilities section at the end of this tutorial.
If your systemctl
output does not give specific information about the IP address and port or ports that are causing the AH00072 error, you will need to examine journalctl
output from the systemd
logs. The following section explains how to use journalctl
to troubleshoot an AH00072 error.
journalctl
LogsIf your systemctl
output does not include specifics about an AH00072 error, you should proceed with using the journalctl
command to examine systemd
logs for Apache.
On Ubuntu and Debian-derived systems, run the following command:
- sudo journalctl -u apache2.service --since today --no-pager
On CentOS, Fedora, and RedHat-derived systems, use this command to inspect the logs:
- sudo journalctl -u httpd.service --since today --no-pager
The --since today
flag will limit the output of the command to log entries beginning at 00:00:00 of the current day only. Using this option will help restrict the volume of log entries that you need to examine when checking for errors.
If Apache is unable to bind to a port that is in use, search through the output for lines that are similar to the following log entries, specifically lines that contain the AH00072 error code as highlighted in this example:
Output-- Logs begin at Tue 2020-07-14 20:10:37 UTC, end at Tue 2020-07-28 14:01:40 UTC. --
. . .
Jul 28 14:03:01 b06f9c91975d apachectl[71]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Jul 28 14:03:01 b06f9c91975d apachectl[71]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jul 28 14:03:01 b06f9c91975d apachectl[71]: no listening sockets available, shutting down
This output indicates two AH00072 errors. The first of these explains that Apache cannot bind to the [::]:80
address, which is port 80
on all available IPv6 interfaces. The next line, with the address 0.0.0.0:80
, indicates Apache cannot bind to port 80
on all available IPv4 interfaces. Depending on your system’s configuration, the IP addresses may be different and only show individual IPs, and may only include IPv4 or IPv6 errors.
Even though your own system may have different conflicting interfaces and ports, the errors will be similar to the output shown here. With output from journalctl
you will be able to diagnose the issue using ss
in the following section of this tutorial.
ss
and ps
UtilitiesTo troubleshoot an AH00072 error you need to determine what other process is listening on the IP address and port that Apache is attempting to use. Most modern Linux distributions include a utility called ss
which can be used to gather information about the state of a system’s network sockets.
In the previous journalctl
section, something was already bound to the IPv4 and IPv6 addresses on port 80
. The following command will determine the name of the process that is already bound to an IPv4 interface on port 80
. Ensure that you substitute the port from the error message if it is different from 80
in the following command:
- sudo ss -4 -tlnp | grep 80
The flags to the ss
command alter its default output in the following ways:
-4
restricts ss
to only display IPv4-related socket information.-t
restricts the output to tcp
sockets only.-l
displays all listening sockets with the -4
and -t
restrictions taken into account.-n
ensures that port numbers are displayed, as opposed to protocol names like ‘httpor
https`. This is important since Apache may be attempting to bind to a non-standard port and a service name can be confusing as opposed to the actual port number.-p
outputs information about the process that is bound to a port.With all of those flags, you will receive output like the following:
OutputLISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=40,fd=6))
The first three fields are not important when troubleshooting an AH00072 error so they can be ignored. The important fields are the fourth (0.0.0.0:80
), which matches the journalctl
error that you discovered earlier, along with the last users:(("nginx",pid=40,fd=6))
, specifically the pid=40
portion.
If you have an AH00072 error that is related to an IPv6 interface, repeat the ss
invocation, this time using the -6
flag to restrict the interfaces to the IPv6 network stack like this:
- sudo ss -6 -tlnp |grep 80
OutputLISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=40,fd=7))
Again, substitute the port number in question from your journalctl
output if it is different from the highlighted 80
given here.
In both these cases of IPv4 and IPv6 errors, the ss
output indicates that there is a program with process ID 40 (the pid=40
in the output) that is bound to the 0.0.0.0:80
and [::]:80
interfaces respectively. This process is preventing Apache from starting since it already owns the port. To determine the name of the program, use the ps
utility like this, substituting the process ID from your output in place of the highlighted 40
value in this example:
- sudo ps -p 40
You will receive output that is similar to the following:
OutputPID TTY TIME CMD
40 ? 00:00:00 nginx
The highlighted nginx
in the output is the name of the process that is listening on the interfaces. Now that you have the name of the program that is preventing Apache from starting, you can decide how to resolve the error. You could stop the nginx
process, reconfigure nginx
to listen on a different interface and port, or reconfigure Apache to avoid the port collision.
It is important to note that the process may be different from nginx
and the port and IP addresses may not always be 0.0.0.0
or [::]
if you are diagnosing an AH00072 error. Oftentimes, different web servers and proxies will be in use on the same server. Each may be attempting to bind to different IPv4 ports and IPv6 interfaces to handle different web traffic. For example, a server that is configured with HAProxy listening on the IPv4 loopback address (also referred to as localhost
) on port 8080
will show ss
output like this:
OutputLISTEN 0 2000 127.0.0.1:8080 0.0.0.0:* users:(("haproxy",pid=545,fd=7))
It is important to combine systemctl
output, or journalctl
output that indicates specific IP addresses and ports, with diagnostic data from ss
, and then ps
to narrow down the process that is causing Apache to fail to start.
In this tutorial you learned how to troubleshoot an Apache AH00072 make_sock: could not bind to address
error message on both IPv4 and IPv6 interfaces. You learned how to use systemctl
to examine the status of the Apache server and try to find error messages. You also learned how to use journalctl
to examine the systemd
logs for specific information about an AH00072 error.
With the appropriate error messages from the logs, you then learned about the ss
utility and how to use it to examine the state of a system’s network sockets. After that you learned how to combine process ID information from ss
with the ps
utility to find the name of the process that is causing Apache to be unable to start.
Tutorial
Updated on September 1, 2022
An Apache AH00558: Could not reliably determine the server's fully qualified domain name
message is generated when Apache is not configured with a global ServerName
directive. The message is mainly for informational purposes, and an AH00558 error will not prevent Apache from running correctly.
In this tutorial you will learn how to detect an AH00558 message using the methods described in the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series. You will also learn how to set a ServerName
directive to resolve the message.
If you have already determined that your Apache server is affected by an AH00558 message and you would like to skip the troubleshooting steps, the Setting a Global ServerName
Directive step at the end of this tutorial explains how to resolve the message.
systemctl
The first step when you are troubleshooting an AH00558: Could not reliably determine the server's fully qualified domain name
message is to check Apache’s status using systemctl
. The output from systemctl
will in many cases contain all the information that you need to resolve the message.
On Ubuntu and Debian-derived Linux distributions, run the following to check Apache’s status:
- sudo systemctl status apache2.service -l --no-pager
On Rocky Linux, Fedora, and Red Hat-derived systems, use this command to examine Apache’s status:
- sudo systemctl status httpd.service -l --no-pager
The -l
flag will ensure that systemctl
outputs the entire contents of a line, instead of substituting in ellipses (…
) for long lines. The --no-pager
flag will output the entire log to your screen without invoking a tool like less
that only shows a screen of content at a time.
You should receive output that is similar to the following:
Output● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: active (running) since Wed 2020-07-29 14:30:03 UTC; 33min ago
Process: 34 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 46 (apache2)
Tasks: 55 (limit: 2344)
CGroup: /system.slice/apache2.service
├─46 /usr/sbin/apache2 -k start
├─47 /usr/sbin/apache2 -k start
└─48 /usr/sbin/apache2 -k start
Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Starting The Apache HTTP Server...
Jul 29 14:30:03 68e2cf19f3f1 apachectl[34]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Started The Apache HTTP Server.
The highlighted line that contains the AH00558 message is the important one. Essentially, it informs you that Apache couldn’t find a valid ServerName
directive in its configuration file, so it will use the first IP address it detects. In this example, it’s the server’s public IP address: 172.17.02
. If you are troubleshooting an AH00558 message, the IP address that is detected may be different, or it may be a human readable DNS name.
If your systemctl
output contains an auto-detected value of any IP address or hostname, skip to the last section of this tutorial, Setting a Global ServerName
Directive to resolve the issue. In that section you will configure Apache with a safe default ServerName
value using the IP address for localhost
: 127.0.0.1
.
If your systemctl
output does not indicate a value that you can use for the ServerName
directive, the next section of this tutorial explains how to examine the systemd
logs using journalctl
to locate an AH00558 message.
journalctl
To examine the systemd
logs for Apache you will use the journalctl
command. When invoking journalctl
, there are two specific flags that will help you locate specific messages if there is a large volume of log entries.
The first flag that you will add to the journalctl
invocation is the --since today
flag. It will limit the output of the command to log entries beginning at 00:00:00 of the current day only. Using this option will help restrict the volume of log entries that you need to examine when checking for errors.
The second flag that you will use is the same --no-pager
option that you used with systemctl
, which will output the entire log to your screen at once.
On Ubuntu and Debian-derived systems, run the following command:
- sudo journalctl -u apache2.service --since today --no-pager
On Rocky Linux, Fedora, and Red Hat-derived systems, use this command to inspect the logs:
- sudo journalctl -u httpd.service --since today --no-pager
If your Apache server is generating an AH00558 message, look through the journalctl
command output for lines like the following:
Output-- Logs begin at Wed 2020-07-29 14:30:02 UTC, end at Wed 2020-07-29 14:45:03 UTC. --
. . .
Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Starting The Apache HTTP Server...
Jul 29 14:30:03 68e2cf19f3f1 apachectl[34]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Started The Apache HTTP Server.
The second line of output is the AH00558 message. The line includes the server’s public IP address, which is the address that Apache automatically detects and sets as a default at runtime. With this message as confirmation of an AH00558 error, you can proceed to the Setting a Global ServerName
Directive to resolve the issue.
Otherwise, the next section explains how to diagnose an AH00558 error message using the apachectl
command.
apachectl
An AH00558: Could not reliably determine the server's fully qualified domain name
error can be detected using Apache’s apachectl
utility. With apachectl
you can catch messages like these before reloading or restarting Apache, and you can avoid having to search through systemctl
and journalctl
logs to locate errors.
To check your Apache configuration for an AH00558 message, run the following command:
- sudo apachectl configtest
You should receive output like the following if your server is affected by an AH00558 error message:
OutputAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
Syntax OK
As with the previous sections in this tutorial that used systemctl
and journalctl
to locate AH00558 messages, the line that contains the AH00558 message, highlighted in the previous example, is the important one. Again note that the IP address 172.17.0.2
in this example may be different on your server.
The next section of this tutorial explains how to set the ServerName
directive to resolve AH00558 error messages.
ServerName
DirectiveTo resolve an AH00558: Could not reliably determine the server's fully qualified domain name
error message, you will need to add a ServerName
directive to your Apache configuration. Apache uses the ServerName
directive to map incoming HTTP requests to an IP address or DNS hostname using VirtualHost
directives in order to handle requests for multiple sites using a single server.
The error message notes that a global ServerName
directive should also be set. Doing so will ensure that Apache can gracefully handle incoming requests that do not map to a VirtualHost
without generating additional errors.
For maximum compatibility with various Apache configurations, use the value of 127.0.0.1
for your global ServerName
directive. You can use a different IP address or DNS name that corresponds to your server’s configuration if you need to, but it is safest to use 127.0.0.1
.
On Ubuntu and Debian-derived systems, open the /etc/apache2/apache2.conf
file with root privileges using nano
or your preferred text editor:
- sudo nano /etc/apache2/apache2.conf
Add a line containing ServerName 127.0.0.1
to the end of the file:
. . .
# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
ServerName 127.0.0.1
On Rocky Linux, Fedora, and Red Hat-derived systems, open the /etc/httpd/conf/httpd.conf
file with root privileges using nano
or your preferred text editor:
- sudo nano /etc/httpd/conf/httpd.conf
Add the ServerName 127.0.0.1
line to the end of the file:
. . .
# Supplemental configuration
#
# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf
ServerName 127.0.0.1
Save and close the file when you are finished. If you used nano
, do so by pressing CTRL + X
, Y
, and then ENTER
.
Once you have added the ServerName
directive to your configuration, run apachectl
to test that the configuration is valid.
- sudo apachectl configtest
A successful apachectl configtest
invocation should result in output like this:
OutputSyntax OK
You can now reload Apache’s configuration using the appropriate systemctl reload
command for your Linux distribution.
On Ubuntu and Debian-derived systems, run the following:
- sudo systemctl reload apache2.service
On Rocky Linux, Fedora, and Red Hat-derived systems use this command to reload Apache’s configuration:
- sudo systemctl reload httpd.service
After you reload Apache, the AH00558 error message will no longer appear in your logs. You can confirm the messages are silenced by running any of the three systemctl
, journalctl
, or apachectl
commands that are demonstrated in this tutorial.
In this tutorial you learned about AH00558: Could not reliably determine the server's fully qualified domain name
error messages. While these messages do not prevent Apache from running, they can be resolved by setting a global ServerName
directive.
You learned how to search for AH00558 error messages using the systemctl
, journalctl
, and apachectl
commands. Finally, you learned how to edit your Apache configuration on various Linux distributions to silence the messages.
If you would like to learn more about how Apache uses ServerName
directives, the Apache documentation about Name-Based Virtual Hosts explains the directive in more detail.
Tutorial
Published on August 6, 2020
Apache generates an AH02572: Failed to configure at least one certificate and key
error message when it is configured to use the ssl
module, but is missing a TLS/SSL public certificate and corresponding private key. The error will prevent Apache from starting up, and the error message itself will be found in Apache’s logs.
In this tutorial you will learn how to troubleshoot an AH02572 error using the methods described in the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series. You will also learn how to set the SSLCertificateFile
and SSLCertificateKeyFile
directives to resolve the message.
If you have already determined that your Apache server is affected by an AH02572 error and you would like to skip the troubleshooting steps, the Adding an SSL Certificate to Apache section at the end of this tutorial explains how to resolve the error.
systemctl
When you are troubleshooting an AH02572: Failed to configure at least one certificate and key
error message, Apache will not be running. Its systemctl
status will show a failed
message.
To examine Apache’s status with systemctl
, run the following command on Ubuntu and Debian derived Linux distributions:
- sudo systemctl status apache2.service -l --no-pager
On CentOS and Fedora systems, use this command to examine Apache’s status:
- sudo systemctl status httpd.service -l --no-pager
The -l
flag will ensure that systemctl
outputs the entire contents of a line, instead of substituting in ellipses (…
) for long lines. The --no-pager
flag will output the entire log to your screen without invoking a tool like less
that only shows a screen of content at a time.
You should receive output that is similar to the following:
Output● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: failed (Result: exit-code) since Fri 2020-07-31 16:02:41 UTC; 20s ago
Process: 36 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
Jul 31 16:02:41 7d6ef84b6907 systemd[1]: Starting The Apache HTTP Server...
Jul 31 16:02:41 7d6ef84b6907 apachectl[36]: Action 'start' failed.
Jul 31 16:02:41 7d6ef84b6907 apachectl[36]: The Apache error log may have more information.
Jul 31 16:02:41 7d6ef84b6907 systemd[1]: apache2.service: Control process exited, code=exited status=1
Jul 31 16:02:41 7d6ef84b6907 systemd[1]: apache2.service: Failed with result 'exit-code'.
Jul 31 16:02:41 7d6ef84b6907 systemd[1]: Failed to start The Apache HTTP Server.
The important lines to note are the ones showing that Apache failed to start. However, there is nothing in the output that indicates an AH02572 error message. Examining the systemd
logs for Apache using the journalctl
command, or checking Apache’s configuration files with apachectl configtest
will not help locate information that you can use to troubleshoot the error.
To diagnose and resolve an AH02572 error, the next section explains how to examine Apache’s logs directly.
Apache logs diagnostic information about its internal operations to various locations, which differ depending on your Linux distribution. Typically, Apache is configured to log error messages to a separate log file from access requests in order to help with debugging, monitoring, and alerting.
On Ubuntu and Debian-derived systems, Apache defaults to using /var/log/apache2/error.log
for error messages.
On CentOS, Fedora, and RedHat-derived systems, Apache defaults to logging errors to the /var/log/httpd/error_log
file.
To examine Apache’s logs for evidence of an AH02572 error message, use the grep
utility to search for the error code in the appropriate log file for your distribution. While there are other tools like less
that you could use to find evidence of an AH02572 error, grep
will only display lines with the error code so you can be sure of whether you’re affected by the issue.
Invoke grep
like this on Ubuntu and Debian-derived systems:
- sudo grep AH02572 /var/log/apache2/error.log
On CentOS, Fedora, and RedHat-derived systems, use the following command:
- sudo grep AH02572 /var/log/httpd/error_log
If your Apache server is affected by an AH02572 error, you will have output like the following:
Output[Mon Aug 03 13:21:47.677235 2020] [ssl:emerg] [pid 26:tid 140355819735360] AH02572: Failed to configure at least one certificate and key for 203.0.113.0:443
If your server is affected by an AH02572 error, the next section of this tutorial explains how to resolve it, by either disabling the ssl
module, or configuring Apache with a private key and public certificate file.
There are three ways to resolve an AH02572 error. The first option to resolve the error is to configure Apache with a private key and public certificate that is signed by a recognized Certificate Authority (CA). Let’s Encrypt is a free CA and you can use it to issue a valid certificate. This approach will ensure that traffic to and from your server is encrypted properly, and that web browsers and other HTTP clients trust your Apache server.
Another approach is to create a self-signed certificate for your Apache server. This approach is useful for development and testing environments, or in cases where your server is not directly connected to the Internet and you can establish trust between systems manually.
The last approach to resolving an AH02572 error is to turn off Apache’s ssl
module entirely. This option is the least preferred since traffic to and from your server will not be encrypted. However, if you are only using your Apache server for local development or in a trusted environment, this approach can be valid.
The following sections explain how to resolve an AH02572 error using each of the three options.
To encrypt traffic to your Apache server using a free Let’s Encrypt TLS Certificate, use one of the guides that is specific to your Linux distribution from this tutorial series: How To Secure Apache with Let’s Encrypt.
The Let’s Encrypt process is mostly automated, and the scripts will configure Apache for you. Moreover, the issued certificate will also be renewed automatically so you do not have to worry about it expiring in the future.
If you are using a Linux distribution that is not included in the How To Secure Apache with Let’s Encrypt series, the Let’s Encrypt documentation includes links to interactive Certbot instructions that can help you configure your Apache server with a valid TLS certificate.
To encrypt traffic to your Apache server using a self-signed certificate, use one of the tutorials from this series that explains how to create Self-signed SSL Certificates with Apache.
These tutorials demonstrate how to generate a private key and public certificate for your Apache server. They also demonstrate how to use the SSLCertificateFile
and SSLCertificateKeyFile
Apache directives to configure your server with the certificate that you generate.
If you are not using a distribution that is listed in the Self-signed SSL Certificates with Apache set of tutorials, this OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs guide can help you create a private key and self-signed public certificate that you can use with Apache.
Note: Where possible, it is best to use a free Let’s Encrypt certificate, or other commercially issued TLS certificate. Self-signed TLS certificates are not trusted by default by browsers and other HTTP clients. As a result, your users will see a security error when visiting your site. However, if you are doing local development, or your use case does not require a valid TLS certificate you can opt for the self-signed approach.
ssl
ModuleThe last approach to resolving an AH02572 error is to turn off Apache’s TLS/SSL support by disabling the ssl
module. This approach is less desirable than encrypting traffic to your server with a TLS certificate, so be certain that you do not need TLS support before disabling the module.
To disable Apache’s ssl
module on Ubuntu and Debian-derived systems, run the following command:
- sudo a2dismod ssl
On CentOS, Fedora, and RedHat-derived systems, disable the module with the following command:
- sudo rm /etc/httpd/conf.modules.d/00-ssl.conf
Once you have disabled the ssl
module, run apachectl
to test that the configuration is valid.
- sudo apachectl configtest
A successful apachectl configtest
invocation should result in output like this:
OutputSyntax OK
You can now restart Apache using the appropriate systemctl restart
command for your Linux distribution.
On Ubuntu and Debian-derived systems, run the following:
- sudo systemctl restart apache2.service
On CentOS, Fedora, and RedHat-derived systems use this command to restart Apache:
- sudo systemctl restart httpd.service
If there are no errors from the systemctl
command then you have disabled the ssl
module successfully.
AH02572: Failed to configure at least one certificate and key
errors are challenging to detect and troubleshoot. They cannot be diagnosed with the usual systemctl
, journalctl
, and apachectl
commands. In this tutorial you learned how to use the grep
utility to examine Apache’s logs directly for evidence of an AH02572 error.
Next you learned how to use Let’s Encrypt to configure Apache with a TLS certificate to secure your traffic and resolve the AH02572 error. You also learned about using self-signed TLS certificates for development and isolated environments. Finally you learned how to turn off the ssl
module for those situations where it is not needed.