How to view MySQL or MariaDB error log

The MySQL and MariaDB error log is the fastest way to turn “it won’t start” into a real diagnosis, because startup, shutdown, crash recovery, and configuration complaints all land in one place.

The database daemon (mysqld or mariadbd) writes error messages to a destination controlled by server options such as log_error plus distribution packaging defaults. On many Linux systems using systemd, the service unit can capture stderr and store the same messages in systemd-journald instead of a traditional file under /var/log/.

Reading the error log commonly requires root or a privileged database account, and the contents can include internal paths, usernames, plugin names, and sometimes fragments of statements, so logs are best treated as sensitive. Rotated logs may appear as numbered siblings (for example, error.log.1) or compressed archives (for example, .gz), so older incidents may live outside the current file.

1. Discover the systemd unit name used by the database service.

   $ systemctl list-units --type=service --all 'mysql*' 'mariadb*' 'mysqld*'
     UNIT            LOAD   ACTIVE SUB     DESCRIPTION
     mariadb.service loaded active running MariaDB database server
   ##### snipped #####

   Common unit names include mysql.service, mariadb.service, and mysqld.service.

2. Read the error log destination from the running server via log_error.

   $ sudo mysql --batch --skip-column-names --execute "SHOW VARIABLES LIKE 'log_error';"
   log_error	/var/log/mysql/error.log

   Socket-auth installs often support sudo mysql, and password-based installs typically use mysql --user=root --password.

3. Read datadir when log_error is a relative path.

   $ sudo mysql --batch --skip-column-names --execute "SHOW VARIABLES LIKE 'datadir';"
   datadir	/var/lib/mysql/

   A log_error value like ./db1.err lives under datadir.

4. Verify the error log file exists on disk when log_error points to a file.

   $ sudo ls -l /var/log/mysql/error.log
   -rw-r----- 1 mysql adm 182734 Dec 12 20:44 /var/log/mysql/error.log

   A missing file with log_error=stderr is expected when logging is routed to systemd-journald.

5. Open the error log file in less using the path reported by log_error.

   $ sudo less /var/log/mysql/error.log

   Use /text to search forward, n for next match, and q to quit.

6. Print the last 200 lines of the error log file for quick triage.

   $ sudo tail --lines=200 /var/log/mysql/error.log
   2025-12-12T20:41:59.123456Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.36) starting as process 1837
   2025-12-12T20:42:00.015902Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
   2025-12-12T20:42:00.198771Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure in thread 140079013246720 in file srv0start.cc line 1284
   ##### snipped #####

   Paste logs into tickets only after removing hostnames, usernames, internal paths, and any query text that should not leave the environment.

7. Follow the error log file live while reproducing the issue.

   $ sudo tail --follow=name --retry /var/log/mysql/error.log
   2025-12-12T20:43:11.774510Z 24 [Warning] [MY-010055] [Server] IP address '10.0.0.12' could not be resolved: Name or service not known
   ##### snipped #####

8. Read the error log from systemd-journald when log_error is set to stderr.

   $ sudo journalctl --unit=mariadb.service --no-pager --lines=200
   Dec 12 20:41:59 db1 mariadbd[1837]: 2025-12-12 20:41:59 0 [Note] mariadbd (server 10.11.6-MariaDB) starting as process 1837
   Dec 12 20:42:03 db1 mariadbd[1837]: 2025-12-12 20:42:03 0 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
   ##### snipped #####

   Swap mariadb.service for the unit name discovered earlier when the service uses a different label.

9. Filter the journal to recent high-severity messages when the log is noisy.

   $ sudo journalctl --unit=mariadb.service --since "1 hour ago" --priority=0..3 --no-pager
   Dec 12 20:42:03 db1 mariadbd[1837]: 2025-12-12 20:42:03 0 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
   ##### snipped #####

10. Search common configuration paths for an explicit log_error setting when the destination is unclear.

    $ sudo grep --recursive --line-number --extended-regexp '^[[:space:]]*(log_error|log-error)[[:space:]]*=' /etc/mysql /etc/my.cnf /etc/my.cnf.d 2>/dev/null
    /etc/mysql/mysql.conf.d/mysqld.cnf:18:log_error = /var/log/mysql/error.log

    Changing /etc/mysql/ or /etc/my.cnf/ does not move existing logs automatically, and a restart is usually required to apply a new destination.

11. List rotated siblings of the error log when older entries are needed.

    $ sudo ls -lh /var/log/mysql/error.log*
    -rw-r----- 1 mysql adm 182K Dec 12 20:44 /var/log/mysql/error.log
    -rw-r----- 1 mysql adm  96K Dec 11 06:10 /var/log/mysql/error.log.1
    -rw-r----- 1 mysql adm  12K Dec 10 03:21 /var/log/mysql/error.log.2.gz

    Use zless or zgrep for .gz logs to avoid manual decompression.