MySQL error logs on Plesk-managed Ubuntu servers are typically located in /var/log/mysql/error.log or the directory specified by the log_error variable. If the standard path is missing, you can locate the correct file by checking the MySQL configuration files in /etc/mysql/ or querying the running instance directly using the SHOW VARIABLES command.
Understanding the Standard Location
On a standard Ubuntu installation, the MySQL server writes its error log to/var/log/mysql/error.log. However, Plesk often modifies these defaults to ensure better integration with its own monitoring and logging systems. It is crucial not to assume the location without verification, as moving or deleting files in this directory can disrupt service stability if permissions are incorrect. The primary goal is to identify where the database engine is currently configured to write diagnostic information rather than guessing based on generic documentation.
You should first check if the file exists at the default path. Use the following command to list the details of the log file:
ls -l /var/log/mysql/error.logmysql:mysql) to write to it safely. Incorrect permissions will cause the database to fail to start or log errors silently.
Locating the Active Configuration
Plesk manages MySQL configurations through a combination of system-wide files and domain-specific overrides. The most reliable way to find the active error log path is to inspect the MySQL configuration hierarchy. Start by examining the main configuration file for any custom settings.grep -i "log_error" /etc/mysql/my.cnf
grep -i "log_error" /etc/mysql/mysql.conf.d/mysqld.cnflog_error. If found, the value following the equals sign is your target path. For example, you might see log_error=/var/log/mysql/error.log or a custom path like /var/log/plesk/mysql/error.log. If no explicit path is set in these files, MySQL defaults to the hostname followed by .err in the data directory, which is rarely used in modern Plesk setups but remains a fallback.
For deeper inspection, you can also check the Plesk-specific configuration directories. While paths may vary slightly between versions, look for files in /etc/mysql/conf.d/ or similar subdirectories within /etc/mysql/. These files often contain overrides applied by Plesk during updates or domain provisioning. Be cautious when editing these files; always back them up before making changes.
Querying the Running Instance
If the configuration files do not provide clarity, or if you suspect a runtime override, you can query the MySQL server directly. This method shows the effective setting currently in use by the daemon. Connect to your MySQL server using the root user:mysql -u admin -p`cat /etc/psa/.psa.shadow`SHOW VARIABLES LIKE 'log_error';/var/log/mysql/error.log. Write down this path and exit the client. This confirms the definitive location without relying on static config files that might be overridden by other mechanisms.
Accessing and Managing Logs Safely
Once you have identified the correct log file, you can view its contents using standard Linux tools. To watch the log in real-time as errors occur, use thetail command with the -f flag:
tail -f /path/to/your/error.log/path/to/your/error.log with the actual path found in the previous steps. This allows you to monitor database activity and catch startup failures or permission issues instantly. When troubleshooting, look for entries containing "ERROR" or "Warning" near the timestamp of the incident.
It is vital to handle log rotation correctly. On Ubuntu, logrotate usually manages these files automatically. Never truncate the log file by simply deleting its contents while the service is running, as this can lead to lost data or file descriptor issues. Instead, rely on the system's rotation scripts or use cp /dev/null > /path/to/log only if you understand the implications for open file handles. For routine maintenance, ensure that disk space is monitored, as full logs can prevent MySQL from writing new entries, potentially causing silent failures.
For more advanced troubleshooting related to script execution errors in automated tasks, you might find our guide on Fixing the 'Unsupported key' Error when Running a Script from Zabbix GUI helpful, as it covers similar diagnostic approaches for system-level failures.
Frequently Asked Questions
Why is my MySQL error log empty?
An empty log usually means the server has not encountered any errors since the last rotation or startup, or the logging level is set too high. Check the log_error_verbosity variable to ensure warnings are not being suppressed. If the server recently crashed, verify that the log file was not deleted during a failed shutdown sequence.
Can I change the MySQL error log location?
Yes, you can change the location by modifying the log_error directive in your MySQL configuration files. After changing the path, you must restart the MySQL service for the change to take effect. Ensure the new directory exists and has the correct permissions for the MySQL user.
How do I rotate MySQL logs manually?
You can trigger log rotation using the logrotate utility with the force flag: sudo logrotate -f /etc/logrotate.d/mysql-server. This ensures that old logs are archived and new ones are created cleanly. Always verify that the MySQL service continues to write to the new file after rotation.
What if the log file is owned by root?
If the log file is owned by root, MySQL cannot write to it, leading to startup failures. Fix this by changing the ownership to the mysql user: sudo chown mysql:mysql /var/log/mysql/error.log. Then, restart the MySQL service to apply the fix.
Where are Plesk-specific database logs stored?
Plesk may store additional database-related logs in /var/log/plesk/, such as db_backup.log or task execution logs. These are distinct from the core MySQL error log and are useful for debugging backup processes or panel interactions rather than database engine errors.