Score:0

MariaDB log_error system variable, configuration file difference between Ubuntu 20.04 and 22.04

in flag

Ubuntu 20.04 (Focal Fossa)

# dpkg -l | grep mariadb-server-10
ii  mariadb-server-10.3             1:10.3.38-0ubuntu0.20.04.1        amd64        MariaDB database server binaries

# grep -E 'skip_log_error|syslog|log_error' /etc/mysql/ -R | grep -v '#'
/etc/mysql/mariadb.conf.d/50-server.cnf:log_error = /var/log/mysql/error.log
/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf:skip_log_error
/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf:syslog

# tail -2 /var/log/mysql/error.log
2023-07-28  8:30:23 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.3.38-MariaDB-0ubuntu0.20.04.1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 20.04

Ubuntu 22.04 (Jammy Jellyfish)

# dpkg -l | grep mariadb-server-10
ii  mariadb-server-10.6             1:10.6.12-0ubuntu0.22.04.1

# grep -E 'skip_log_error|syslog|log_error' /etc/mysql/ -R | grep -v '#'
/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf:skip_log_error
/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf:syslog

# tail -2 /var/log/mysql/error.log
tail: cannot open '/var/log/mysql/error.log' for reading: No such file or directory

Up until Ubuntu 22.04, the MariaDB log was written to /var/log/mysql/error.log. Since the log_error system variable has apparently been removed in Ubuntu 22.04 from /etc/mysql/mariadb.conf.d/50-server.cnf, this isn't the case anymore.

  • Why was log_error removed from the configuration file /etc/mysql/mariadb.conf.d/50-server.cnf?
  • Why was the log file /var/log/mysql/error.log still created in Ubuntu 20.04, even though skip_log_error was used by default?
    • I assume this is due to the order in which the configuration files are processed, if so, where can I see this?

Side note
The log file did not exist before MariaDB was installed.

# ls /var/log/mysql/error.log
ls: cannot access '/var/log/mysql/error.log': No such file or directory
# dpkg -l | grep mariadb-server-10
# apt install mariadb-server
(...)
# dpkg -l | grep mariadb-server-10
ii  mariadb-server-10.3             1:10.3.38-0ubuntu0.20.04.1        amd64        MariaDB database server binaries
# ls /var/log/mysql/error.log
/var/log/mysql/error.log
Score:0
in flag

Are you sure you didn't set log_error before in the past?

In mariadb select the variable to see the value:

select @@log_error

For as long as I can remember systemd being used, log_error has defauled to no value so the error log is written to STDOUT/STDERR so systemd can catch it.

You can still read the log data with journalctl:

journalctl -u mariadb.service

EDIT: looking at that file, it can be ignored:

$ cat /etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf
# NOTE: THIS FILE IS READ ONLY BY THE TRADITIONAL SYSV INIT SCRIPT, NOT SYSTEMD.
# MARIADB SYSTEMD DOES _NOT_ UTILIZE MYSQLD_SAFE NOR READ THIS FILE.
#
# For similar behavior, systemd users should create the following file:
# /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf
#
# To achieve the same result as the default 50-mysqld_safe.cnf, please create
# /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf
# with the following contents:
# [Service]
# User = mysql
# StandardOutput = syslog
# StandardError = syslog
# SyslogFacility = daemon
# SyslogLevel = err
# SyslogIdentifier = mysqld
#
# For more information, please read https://mariadb.com/kb/en/mariadb/systemd/
obeN avatar
in flag
Yes, both servers are freshly installed, they were test environments with fresh OS and manual MariaDB installations. No configurations were changed during, before or after testing.
obeN avatar
in flag
Also, afaik, things like InnoDB corruption would not be logged in journalctl in this case.
Score:0
in flag

The log_error system variable has been removed by MariaDB here: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/bb8477778b72f047437b2a03a2bd38997e155f10#d3b22343b539ed028e5c8bf973b769b861541893_63_62

The reason why logging still worked in Ubuntu 20.04 even though skip_log_error was configured is due to the file order.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.