MySQL Bugs: #102846: default error log file is with name of mariadb ? Any reason

Bug #102846	default error log file is with name of mariadb ? Any reason
Submitted:	7 Mar 2021 12:44	Modified:	11 Apr 2021 7:06
Reporter:	Ankit Kapoor	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S6 (Debug Builds)
Version:	8.0.23	OS:	Linux
Assigned to:		CPU Architecture:	Any
Tags:	MariaDB, MySQL

Description:
I am not sure if this could be counted as a built bug because it is not causing any blocker while working but I am just curious to understand as why the default error log file and pid file is creating with the name of mariadb.

How to repeat:
How to repeat :

1. Download the package mysql-8.0.23-linux-glibc2.12-x86_64.tar.xz
2. Unzip it.
3. run mysqld to initialise the database.
4. Check the /etc/my.cnf file
5. Under mysqld_safe section , error log file and pid file is being created with the name of mariadb.

Suggested fix:
Change the default file name which get created post mysqld

The tarball don't ship any my.cnf file and don't ship any files outside the normal unpacked directory mysql-...

If you have /etc/my.cnf or other mysql files around there origin are from other sources. 

(However, mysql might use /etc/my.cnf if present, it's up to DBA to control the origin and contents of the file.)

If you don't want MySQL to read /etc/my.cnf look a the --no-defaults and --defaults-file options:

 https://dev.mysql.com/doc/refman/8.0/en/option-file-options.html

Thanks.

"/etc/my.cnf" file got created post running mysqld and my.cnf file got created on its own. Please note I installed mysqld completely on new server and there is no chance to have my.cnf file from other sources.

Have you tried reproducing it ?

my concern is even if mysqld is creating /etc/my.cnf file then how come log error and pid file is of "mariadb"

Can you please describe in detail how you come this to your conclusion?

I can't reproduce:

[root@host]# wget -q https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.23-linux-glibc2.12-x86_64.tar.xz

[root@host]# md5sum mysql-8.0.23-linux-glibc2.12-x86_64.tar.xz
b7228a20ab3f43d830f0f791cb52c229  mysql-8.0.23-linux-glibc2.12-x86_64.tar.xz

[root@host]# tar xf mysql-8.0.23-linux-glibc2.12-x86_64.tar.xz

[root@host]# cd mysql-8.0.23-linux-glibc2.12-x86_64

[root@host mysql-8.0.23-linux-glibc2.12-x86_64]# ls
LICENSE  README  bin  docs  include  lib  man  share  support-files

[root@host mysql-8.0.23-linux-glibc2.12-x86_64]# ls -l /etc/my.cnf 
ls: cannot access '/etc/my.cnf': No such file or directory

[root@host mysql-8.0.23-linux-glibc2.12-x86_64]# bin/mysqld --user=mysql --initialize --datadir=/tmp/my
2021-03-07T17:31:43.794953Z 0 [System] [MY-013169] [Server] /tmp/mysql-8.0.23-linux-glibc2.12-x86_64/bin/mysqld (mysqld 8.0.23) initializing of server in progress as process 119268
2021-03-07T17:31:43.799977Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2021-03-07T17:31:43.955191Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2021-03-07T17:31:44.784735Z 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: +ls(J+a4rohi

[root@host mysql-8.0.23-linux-glibc2.12-x86_64]# ls -l /etc/my.cnf
ls: cannot access '/etc/my.cnf': No such file or directory

There is no /etc/my.cnf present nor before or after initialize.

Hi again,

any other trick you can use is the seen which files MySQL uses to set options.

Try for example this query:

mysql> select * from performance_schema.variables_info where VARIABLE_PATH like '/etc%';

Giving something like:

+---------------+-----------------+---------------+-----------+-----------+----------+----------+----------+
| VARIABLE_NAME | VARIABLE_SOURCE | VARIABLE_PATH | MIN_VALUE | MAX_VALUE | SET_TIME | SET_USER | SET_HOST |
+---------------+-----------------+---------------+-----------+-----------+----------+----------+----------+
| datadir       | GLOBAL          | /etc/my.cnf   | 0         | 0         | NULL     | NULL     | NULL     |
| log_error     | GLOBAL          | /etc/my.cnf   | 0         | 0         | NULL     | NULL     | NULL     |
| pid_file      | GLOBAL          | /etc/my.cnf   | 0         | 0         | NULL     | NULL     | NULL     |
| socket        | GLOBAL          | /etc/my.cnf   | 0         | 0         | NULL     | NULL     | NULL     |
+---------------+-----------------+---------------+-----------+-----------+----------+----------+----------+

And 

mysql> select * from performance_schema.variables_info where VARIABLE_NAME like 'pid_file';

+---------------+-----------------+---------------+-----------+-----------+----------+----------+----------+
| VARIABLE_NAME | VARIABLE_SOURCE | VARIABLE_PATH | MIN_VALUE | MAX_VALUE | SET_TIME | SET_USER | SET_HOST |
+---------------+-----------------+---------------+-----------+-----------+----------+----------+----------+
| pid_file      | GLOBAL          | /etc/my.cnf   | 0         | 0         | NULL     | NULL     | NULL     |
+---------------+-----------------+---------------+-----------+-----------+----------+----------+----------+

When problematic file is found you can use package manager tool for system.

RPM on RHEL/OracleLinux/CentOS:

$ rpm -qf /path/to/my.cnf

dpkg on Debian and Ubuntu systems:

$  dpkg -S /path/to/my.cnf

To get package which is problematic.

Hello,

Sorry for coming late on this and thanks for your follow up and providing the above information.

I tried re producing this and again got this error. But this time I finally realised that error is not with mysql binary files. It is with the VM I am buying from one of the cloud vendor. So issue is whenever I create a VM my.cnf file comes there automatically. Since I never expected this I never thought to check from that angle. See below : 

[root@xyz ~]# ps -ef|grep mysql
root      8266  8226  0 21:25 pts/0    00:00:00 grep --color=auto mysql
[root@xyz ~]# ls -lrth /etc/my.cnf
-rw-r--r--. 1 root root 570 Oct 19 16:29 /etc/my.cnf
[root@xyz ~]#

Hi again!

For future reference what is the output from:

$ rpm -qf /etc/my.cnf 

on that system?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".