One place for hosting & domains

      Errors

      How to Fix Syntax Errors in WordPress


      If you found this article because you’re staring at a WordPress error message where your website used to be, take a deep breath and put on your superhero cape (tights are optional).

      Yes, there’s a problem, but it’s possible to fix it.

      Your site hasn’t disappeared into the ether. It’s still there, behind that error message. The issue may be something as simple as a missing semicolon in a PHP file. WordPress syntax errors aren’t frequent, but they do occur and are relatively simple to correct.

      In this article, we’ll explain what a syntax error is, along with some common causes. Then we’ll walk you through the steps to take to locate and fix the error. Let’s get started!

      What Is a Syntax Error?

      A syntax error occurs when a command is not written correctly.

      A WordPress syntax error message.

      This may include the presence of a grammatical mistake, a misspelled word or missing symbol, or an incorrect punctuation mark in your site’s code. In WordPress, this is usually a PHP error.

      Skip the Stress

      Avoid troubleshooting when you sign up for DreamPress. Our friendly WordPress experts are available 24/7 to help solve website problems — big or small.

      Common Causes of Syntax Errors in WordPress

      A syntax error may occur when you’ve pasted code incorrectly. Maybe you missed a portion when you copied the code or perhaps there is an extra closing tag at the end of the script.

      This is a PHP open tag: <?php, and this is a closing tag: ?>.

      When you copy and paste a PHP code snippet, it often includes the open tag, causing a syntax error. Since you are probably pasting the snippet into existing code, you don’t need to include the open tag.

      You may also get a syntax error when you are editing your theme in the WordPress Customizer. If this happens, you’ll generally know what the problem is, or at least where in the file it’s occurring. If you aren’t sure, don’t worry. You can locate the error by making a few changes to the wp-config.php file.

      Another reason you might see this message is because of a plugin update or installation. The extension may not be compatible with your WordPress version, or there may be other issues at play. If you were updating or installing a plugin when the error happened, that’s most likely the source of the problem.

      Why Fixing the WordPress Syntax Error Matters

      A syntax error is an indication that something isn’t right within your site’s code. This issue can break your website, leaving you with a blank page or error message.

      If your website is down or inaccessible, it will obviously hamper the User Experience (UX). Besides hurting your traffic and conversion rates, having a blank page where your site should be can also hurt your Search Engine Optimization (SEO) rankings.

      WordPress syntax error messages can be concerning, especially if you aren’t familiar with website code. Fortunately, as you’ll see, most syntax errors have a simple solution.

      How to Fix a Syntax Error in WordPress via SFTP

      When a syntax error occurs, you can fix it by either removing or correcting the code containing the error. Either way, you’ll need access to the file where the problem is occurring. If you’re locked out of your WordPress admin dashboard, you can access this by using a File Transfer Protocol (FTP) client.

      If you’re a DreamHost customer, this process is especially easy. There’s no need to download a third-party application. You can access your website files using our dedicated WebFTP tool.

      DreamHost’s WebFTP login screen.

      If you aren’t a DreamHost customer or prefer to use an FTP client, FileZilla is a good option. Note that you’ll always want to connect using the more secure Secure File Transfer Protocol (SFTP) rather than FTP. This will ensure the transferred data is encrypted.

      You will need some information to connect to your website via SFTP:

      • Server/Hostname
      • Username
      • Password
      • Port

      You can find this information by logging into your web hosting account. DreamHost users can navigate to Manage Account. If you’re using another hosting provider, they may call this area something different — if you need help, contact your host or visit their knowledge base.

      From the account management area, look for FTP Users (or FTP Accounts, depending on your web host) and select Manage Users to view your Host, Username, and Port settings. If you don’t know your FTP password, you can reset it with the link provided.

      DreamHost FTP user information.

      Next, open your FTP client and enter your login credentials. Once logged in, under your WordPress site’s directory, you will see the wp-adminwp-content, and wp-includes folders, and a list of other files.

      A WordPress site directory via SFTP.

      If your screen looks similar to the above example, you’re in the right place! Now, it’s time to enable debugging to get more information about the syntax error.

      Enable Debugging to View the Syntax Error Location

      If you were working on your website when the error occurred, you should have a good idea of where to look for the issue. However, if you’re unsure, there’s no need to guess. Debugging will show you the exact location of the error.

      To enable debugging, you can add the following snippet of code to your wp-config.php file:

      define( 'WP_DEBUG', true );

      Be sure to put the code before /* That’s all, stop editing! Happy blogging. */ toward the bottom of the file.

      WordPress debugging code added to the ‘wp-config.php’ file.

      Once you save the file and refresh your website in your browser, you should see a text string indicating the location of the error, including the file, name, and line number.

      A WordPress syntax error message.

      Be sure to disable debugging once you’ve fixed the syntax errors, as leaving this feature on isn’t recommended for live websites.

      You’ve now located the syntax error. After noting the information, it’s time to get to work fixing it. You can use the directions below to address the error according to its location.

      Fix a Syntax Error Caused By a Plugin Update

      If you were installing, updating, or editing a plugin file when the syntax error occurred, the simplest and fastest solution is to disable the plugin. That’s what we’ll do first.

      Access your website via SFTP. Once you’re connected, go to the wp-content/plugins directory, and locate the plugin folder with the error.

      While there, you can either disable the plugin or correct the file that contains the error — if you know what’s causing the issue. If not, you can disable the plugin by renaming its folder in the plugins directory.

      If you go to your website’s URL and refresh the browser, your site should appear normal. However, if you want to continue using the plugin, you’ll need to resolve the error rather than simply disabling it.

      To correct the plugin error, locate the file and line number from the error message. Identify any missing or incorrect code on that line. If you’re unsure what’s causing the error, you can paste the snippet into a code editor to help you identify it.

      You can always disable the plugin as a short-term fix. Then, you can reactivate it later, once the error is corrected. This may be the best approach, especially if the plugin isn’t essential to your website’s operation.

      Fix Syntax Error Caused By Editing a Theme File Improperly

      To fix an error that occurred while editing your theme, access your website via SFTP, and navigate to the wp-content/themes folder. Open the appropriate theme folder and locate the file with the error — usually the functions.php file.

      Edit the file and correct the error. Again, the syntax error code should display the line number. If the problem occurred when you pasted a code snippet into the file, delete your edits to restore the file to its stable version.

      If you don’t see what’s causing the problem, you can use a code editor to help identify the error. Once you correct the problem, open a browser window, and navigate to your URL to verify that your site is up and running again.

      Use a Code Editor to Identify Syntax Errors

      There are several free code editors available online, like Sublime Text and Atom. You can use any of these tools to help diagnose and fix syntax errors.

      In the illustration below, the functions.php file is missing a semicolon on the last line.

      Syntax errors shown in a code editor.

      The editor indicates the syntax error with a yellow bar beside the line number (610). Once we add the semicolon, the error resolves, and the yellow flag disappears. You can practice writing or editing code in an editor before making changes to your website’s files.

      How to Avoid Syntax Errors in the Future

      Using proper syntax can help you avoid errors in the future. PHP is a simple, flexible language. You can invest a little time to learn the basics. Then, when you’re pasting code or making edits to your site’s files, you’ll know how to correct errors as you work.

      As another option, you can keep a code editor handy to check syntax before pasting code into your website. This is a smart practice for ensuring that a code snippet is correct before adding it to files on a live site.

      Another way to prevent issues is to enable debugging when making changes to your site, in order to flag errors before going live. This is the time to make sure everything is compatible with your WordPress core files and works as it should.

      Finally, we suggest deleting any unused plugins and themes. Not only can this help prevent syntax errors, but it is also a good security measure, so it’s a win-win.

      Take Your WordPress Site to the Next Level

      Whether you need help navigating the WordPress dashboard, decoding an error log, or fixing a faulty plugin, we can help! Subscribe to our monthly digest so you never miss an article.

      Ready to Fix That Syntax Error?

      Almost 40% of all websites are built on WordPress, making it the most popular Content Management System (CMS) in the world. It’s a stable and secure platform, but even so, errors can still happen.

      In this article, we explained what syntax errors are and their most common causes. Then we provided a step-by-step guide for fixing syntax errors in your WordPress installation. These are usually simple to resolve, but it’s best to take measures to prevent the problems from appearing in the first place, such as using a code editor to check code before adding it to your site.

      Properly maintaining your website is one of the best ways to avoid issues and keep it running smoothly. DreamPress hosting (with free WordPress migration) is specifically designed for the WordPress environment. Plus, if you ever do encounter a problem, we’ve got you covered with automatic daily backups and a support team of WordPress experts!



      Source link

      How To Troubleshoot Common HAProxy Errors



      Part of the Series:
      Common HAProxy Errors

      This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the HAProxy TCP and HTTP proxy server.

      Each tutorial in this series includes descriptions of common HAProxy configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot HAProxy. Subsequent tutorials examine specific errors in detail.

      Introduction

      There are three main commands, and a common log location that you can use to get started troubleshooting HAProxy errors. Generally when you are troubleshooting HAProxy, you will use these commands in the order indicated here, and then examine the log file for specific diagnostic data.

      The commands and log that you will commonly use to troubleshoot HAProxy 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.
      • haproxy – When troubleshooting, this command is used to check HAProxy’s configuration.
      • /var/log/haproxy.log – This file contains log entries from HAProxy itself detailing TCP and HTTP traffic that is being handled by the server.

      These commands, how to use them, and HAProxy’s logs where you can find additional information about errors are described in further detail in the following sections.

      systemctl Commands for HAProxy

      To troubleshoot common HAProxy errors using the systemd service manager, the first step is to inspect the state of the HAProxy processes on your system. The following systemctl commands will query systemd for the state of HAProxy’s processes on most Linux distributions.

      • sudo systemctl status haproxy.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. If you omit the --no-pager flag you will be able to scroll through the output using arrow keys, or the page up and down keys. To quit from the pager use the q key. You should receive output like this:

      Output

      ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-08-20 19:30:11 UTC; 5s ago Docs: man:haproxy(1) file:/usr/share/doc/haproxy/configuration.txt.gz Process: 487 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS (code=exited, status=0/SUCCESS) Main PID: 488 (haproxy) Tasks: 2 (limit: 2344) . . . Aug 19 21:31:46 d6cdd0c71489 systemd[1]: Started HAProxy Load Balancer.

      Your output may be slightly different depending on which Linux distribution you are using, but in any case, make a note of the Active line in the output. If your HAProxy server does not show active (running) as highlighted in the example output 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 Output

      Active: failed (Result: exit-code) since Thu 2020-08-20 19:32:26 UTC; 6s ago

      If there is a problem with your HAProxy process or configuration you can troubleshoot it further using the journalctl command.

      journalctl Commands for HAProxy

      To inspect the systemd logs for HAProxy, you can use the journalctl command. The systemd logs for HAProxy will usually indicate whether there is a problem with starting or managing the HAProxy process.

      These logs are separate from HAProxy’s request and error logs. journalctl displays logs from systemd that describe the HAProxy service itself, from startup to shutdown, along with any process errors that may be encountered along the way.

      • sudo journalctl -u haproxy.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 (there may be a few extra lines between the Starting and Started lines depending on your Linux distribution):

      Output

      Aug 20 19:37:08 d6cdd0c71489 systemd[1]: Starting HAProxy Load Balancer... . . . Aug 20 19:37:08 d6cdd0c71489 systemd[1]: Started HAProxy Load Balancer.

      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 Output

      Aug 20 19:32:25 yourhostname systemd[1]: Failed to start HAProxy Load Balancer.

      If your HAProxy server has errors in the journalctl logs like the previous example, then the next step to troubleshoot possible issues is investigating HAProxy’s configuration using the haproxy command line tool.

      Troubleshooting with haproxy

      To troubleshoot HAProxy configuration issues, use the haproxy -c command. The tool will parse your HAProxy 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. Be sure to change the path to the configuration file if you are using a different filename or location:

      • sudo haproxy -c -f /etc/haproxy/haproxy.cfg

      A working HAProxy configuration will result in output like the following:

      Output

      Configuration file is valid

      If there is an error in your HAProxy configuration, like a typo or misplaced directive, haproxy -c will detect it and attempt to notify you about the problem.

      For example, attempting to use the bind directive in haproxy.cfg in the wrong location will result in messages like the following:

      Example Error Output

      [ALERT] 232/194354 (199) : parsing [/etc/haproxy/haproxy.cfg:13] : unknown keyword 'bind' in 'global' section [ALERT] 232/194354 (199) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 232/194354 (199) : Fatal errors found in configuration.

      In this example the bind directive is misplaced inside a global configuration section, so HAProxy generates the unknown keyword error. The message also includes a line number 13, so that you can edit the file and fix or remove the erroneous line without having to search through the file.

      Learning how to use haproxy -c to detect and fix errors is useful when you are troubleshooting an existing error, or before you reload HAProxy with an edited configuration that may contain errors.

      HAProxy Log Files

      HAProxy 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 HAProxy’s logs. Sometimes HAProxy will also output errors related to configuration and other debugging information to its log files.

      On Ubuntu and Debian based Linux distributions, the haproxy package includes scripts that configure log output in /var/log/haproxy.log.

      On CentOS, Fedora, and other RedHat-derived Linux distributions, haproxy does not output to a log file by default. To log HAProxy output logs to /var/log/haproxy.log, follow this quickstart tutorial, How To Configure HAProxy Logging with Rsyslog on CentOS 8.

      When you are troubleshooting HAProxy using its log file, examine /var/log/haproxy.log for errors using a tool like tail or less. For example, to view the last two lines of the log using tail, run the following command:

      • sudo tail -n 2 /var/log/haproxy.log

      An example error will resemble something like the following lines, regardless of which Linux distribution you are using to run your HAProxy server:

      Log Examples

      Aug 20 19:36:21 d6cdd0c71489 haproxy[19202]: [ALERT] 258/134605 (19202) : Proxy 'app', server 'app1' [/etc/haproxy/haproxy.cfg:88] verify is enabled by default but no CA file specified. If you're running on a LAN where you're certain to trust the server's certificate, please set an explicit 'verify none' statement on the 'server' line, or use 'ssl-server-verify none' in the global section to disable server-side verifications by default. Aug 20 19:36:22 d6cdd0c71489 haproxy[4451]: 203.0.113.1:54428 [20/Aug/2020:19:36:22.288] main app/<NOSRV> 0/-1/-1/-1/1 503 212 - - SC-- 1/1/0/0/0 0/0 "GET / HTTP/1.1"

      These example lines are just for illustration purposes. If you are diagnosing errors with your HAProxy server, chances are the lines in your logs will have different contents than these. Some lines will include success responses and other non-critical diagnostic entries.

      Regardless of your Linux distribution, the format of the lines in your HAProxy logs will include any HTTP status codes that are returned to clients, along with requesting IPs and the status of backend servers.

      Once you have an idea of what might be causing problems with your HAProxy server you can continue researching and troubleshooting the issue. The HTTP status 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.

      Conclusion

      Troubleshooting HAProxy 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 HAProxy 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 HAProxy server. If you need more information, examine the systemd logs for HAProxy using the journalctl command. If the issue is still not apparent after checking journalctl, testing HAProxy’s configuration using haproxy -c -f /etc/haproxy/haproxy.cfg is the next step. Finally, for in-depth troubleshooting, examining HAProxy’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 HAProxy in more detail.



      Source link

      How To Troubleshoot Common Apache Errors



      Part of the Series:
      Common Apache Errors

      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.

      Series Description

      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.

      Introduction

      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.

      systermctl Commands for Apache

      To 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 Output

      Active: 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 Apache

      To 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:

      Output

      Jul 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:

      Output

      Jul 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 Output

      Jul 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.

      Troubleshooting with 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:

      Output

      Syntax 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 Output

      AH00526: 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

      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.

      Conclusion

      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.



      Source link