Bug #108675 Error log information was provided during mysql initialization
Submitted: 4 Oct 2022 1:46 Modified: 5 Oct 2022 11:43
Reporter: xichao li (OCA) Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:8.0.27 OS:Any
Assigned to: CPU Architecture:Any
Tags: is unusable, newly created data directory

[4 Oct 2022 1:46] xichao li 
Description:
The mysql database instance fails to be initialized due to some reasons. Procedure Mysql ERROR logs always print ERROR level information:
"The newly created data directory /mysql/data by --initialize is unusable. You can remove it."

As a result, users think that it is due to the existence of files in the /mysql/data directory, and ignore the real cause of failure.

How to repeat:
This confirmation is a review of past case summary findings, please simulate a database instance initialization failure scenario, and then confirm the error log file.

Suggested fix:
We can see that the mysql code contains the following code snippet:

static void unireg_abort(int exit_code) {
  ...
  if (opt_initialize && exit_code && !opt_validate_config)
    LogErr(ERROR_LEVEL,
           mysql_initialize_directory_freshly_created
               ? ER_DATA_DIRECTORY_UNUSABLE_DELETABLE
               : ER_DATA_DIRECTORY_UNUSABLE,
           mysql_real_data_home);
  ...
}

That is, when the initial state is satisfied, unireg_abort() directly prints the above exception log when an exception occurs. It is recommended that you do not output this message as an error message to avoid human misunderstanding (the instructions can be explained in the installation documentation).
[4 Oct 2022 12:06] MySQL Verification Team 
Hi Mr. li,

Thank you for your bug report.

However, your report is not detailed enough. 

Can you let us know what was the real reason that datadir was not initialised correctly ???

Since we are testing every single new release of our server and since we have done it on several different operating system and NEVER got an error, what was it that caused the error.  If you do not know the answer to that question, let us know what you have tried to do to cause that error. Hence , a repeatable test case is a absolutely a necessity for the bug report like this.

We also do not see from your report whether you want us to print the true cause of the error or to append our Reference Manual.

The above Manual contains a bullet list of all the causes of such error. Most significant one is that user that initialises MySQL instance does not have sufficient privileges. That is entirely in the domain of the operating system and not under our control. In that case, in many cases, we can not return a correct error message. It is especially a case for multi-threaded programs, like MySQL server, since that information is not thread safe. That was clearly documented in the C 2017 standard.

We need more info from you .....
[5 Oct 2022 8:23] xichao li 
I understand. I looked for a similar case, but I couldn't find one.
Wait until I find it (or someone else does) and then update.
[5 Oct 2022 11:43] MySQL Verification Team 
Hi Mr. li,

We wrote to you before and we shall repeat the same facts once again.

We can not proceed in processing your report, until we have a fully repeatable test case. The one that will always trigger the same error on our latest 8.0 release.

Can't repeat.