Reading error logs to find the real cause

When your website goes down or shows a 500 error, the first place you should check is the error log. But here’s the problem: many website administrators don’t know exactly where to find the logs or how to translate a vague error message like Connection refused into the real cause. In this article, you’ll learn how to find error logs on Linux servers, read their structure, and convert the most common errors into solutions.

1. Where is the Error Log? Standard Paths on a Linux Server

Depending on the service, error logs are stored in different locations. The most common places include:

• System logs: /var/log/syslog or /var/log/messages (depending on the Linux distribution)
• Apache web server logs: /var/log/apache2/error.log (on Ubuntu/Debian) or /var/log/httpd/error_log (on CentOS/RHEL)
• Nginx web server logs: /var/log/nginx/error.log
• MySQL/MariaDB logs: /var/log/mysql/error.log
• PHP-FPM logs: /var/log/php-fpm/error.log or /var/log/php7.4-fpm.log

Accessing these files usually requires root or sudo privileges. Use the following command to view the last 50 lines of the error log:

sudo tail -n 50 /var/log/apache2/error.log

1.1. How to Find Logs for a Specific Service

If you have a specific service like Postfix or Dovecot, the log path may differ. The best approach is to use the journalctl command on systemd-based systems:

sudo journalctl -u nginx.service --since "1 hour ago"

This command shows logs for the Nginx service from the past hour. For MySQL error logs, you can also use mysqladmin:

sudo mysqladmin -u root -p variables | grep log_error

2. Structure of an Error Log Message: What Information Does It Contain?

A typical line from an Apache error log looks like this:

[Mon Oct 21 14:23:45.123456 2025] [php:notice] [pid 12345] [client 192.168.1.1:54321] PHP Notice:  Undefined variable: foo in /var/www/html/index.php on line 15

This message includes the following parts:

• Date and time: Exactly specifies when the error occurred.
• Error level: Such as notice, warning, error, critical. The critical level is more severe.
• Process ID (PID): Useful for tracking concurrent requests.
• Client IP address: Indicates which user experienced the error.
• Error text: Detailed description of the problem.

2.1. Know the Error Levels

In system and web server logs, error levels from least to most important are as follows:

1. debug: Information for debugging, usually ignored.
2. info: Normal events like service startup.
3. notice: Important but non-critical events.
4. warning: Warning, may become a problem.
5. error: Error, service still works but part of it is disrupted.
6. critical: Critical, service may fail.
7. alert: Requires immediate action.
8. emergency: System is about to crash.

For troubleshooting, focus on error levels and above.

3. Translating Error Messages into Real Causes

Many error log messages are vague. Here, we examine the most common errors and their real causes.

3.1. "Connection refused" Error in MySQL

Message: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)

Real cause: The MySQL service is not running or the socket is corrupted. First, check the service status with the following command:

sudo systemctl status mysql

If the service is not active, start it:

sudo systemctl start mysql

If the service is active but the error persists, the socket file may have been deleted. Find the socket path with this command:

mysql -u root -p -h 127.0.0.1

If this works, the issue is with the socket. Recreate the socket file or specify the correct path in the MySQL configuration.

3.2. "Permission denied" Error in Web Server Logs

Message: AH00558: apache2: Could not reliably determine the server's fully qualified domain name

Real cause: This is a warning, not a critical error. It usually occurs due to the absence of a ServerName setting in the Apache configuration file. To fix it, add the following line to /etc/apache2/apache2.conf:

ServerName localhost

Then restart Apache:

sudo systemctl restart apache2

3.3. "PHP Fatal error: Allowed memory size exhausted" Error

Message: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-admin/includes/media.php on line 123

Real cause: The memory allocated to PHP (usually 128 MB) is insufficient to run the script. This error is common in WordPress when uploading large files. To fix it, increase the memory_limit value in the php.ini file:

memory_limit = 256M

Then restart the PHP-FPM service:

sudo systemctl restart php7.4-fpm

3.4. "SSL: error:0A000086:SSL routines::certificate verify failed" Error

Message: SSL: error:0A000086:SSL routines::certificate verify failed

Real cause: Your server’s SSL certificate has expired, is invalid, or the certificate chain is incomplete. Check the certificate expiration date with the following command:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

If the certificate has expired, renew it. If the issue is with the certificate chain, ensure the fullchain.pem and privkey.pem files are correctly placed in the web server configuration.

4. Common Mistakes in Reading Error Logs

Many novice administrators make the following mistakes:

• Looking at the wrong logs: For example, checking the access log instead of the Apache error log. The access log only records requests, not errors.
• Ignoring the time of the error: Old errors may no longer be relevant. Always check logs related to the time the problem occurred.
• Misinterpreting error levels: Assuming a warning is critical and wasting time on it.
• Not using filtering tools: With the grep command, you can filter logs by keyword. For example:

sudo grep "PHP Fatal error" /var/log/apache2/error.log

5. Advanced Tools for Error Log Analysis

For large projects, manually reading logs is impossible. Use the following tools:

• Logwatch: A command-line tool that emails a summary of logs daily. Installation and configuration are simple:

sudo apt install logwatch
sudo logwatch --detail High --mailto admin@example.com --service all --range today

• GoAccess: A web server log analyzer with a terminal interface. You can view access and error logs interactively.
• Fail2ban: For detecting brute-force attacks from error logs and automatically blocking offending IPs.

6. Final Tip: Monitor Logs Automatically

Don’t wait for users to report problems. Use tools like Prometheus and Grafana or even a simple bash script to monitor logs automatically. For example, the following script checks the error log every 5 minutes and sends an email if a critical error is detected:

#!/bin/bash
if sudo tail -n 10 /var/log/apache2/error.log | grep -q "PHP Fatal error"; then
    echo "Critical error on the server!" | mail -s "Alert: PHP Fatal Error" admin@example.com
fi

Run this script with cron every 5 minutes.

Finally, if you’re looking for a comprehensive solution for managing your server, ServerNet web hosting services provide access to full logs and monitoring tools. But more importantly, learning the principles of troubleshooting, which we covered in this article, is key. With practice and using the commands above, you’ll soon be able to quickly analyze any error log and root out the problem.