MySQL Bugs: #89167: Logging when initialising on an existing datadir could be improved.

Bug #89167	Logging when initialising on an existing datadir could be improved.
Submitted:	10 Jan 2018 7:37	Modified:	10 Jan 2018 19:18
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S4 (Feature request)
Version:	5.7.19	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	5.7.19, logging, mysqld initialialisation

Description:
Logging on startup shows:

08:23 : 2018-01-10T05:05:46.449075Z 0 [Note] Ignoring --secure-file-priv value as server is running with --initialize(-insecure) or --bootstrap.
2018-01-10T05:05:46.449734Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.19-log) starting as process 1607 ...
2018-01-10T05:05:46.484259Z 0 [Note] --initialize specifed on an existing data directory.

There are a mix of messages here and I'd be inclined to suggest that a few things are changed to clarify.

How to repeat:
Startup with the required conditions which lead to the current error.

Suggested fix:
Suggested changes are:

1. Change to warning level (maybe even to an error, though MySQL continues to run and log later)
2. be more specific about which options were actually used. This may be important and it clarifies perhaps the cause. So something like:

08:23 : 2018-01-10T05:05:46.449075Z 0 [Note] Ignoring --secure-file-priv value as server is running with --initialize.
08:23 : 2018-01-10T05:05:46.449075Z 0 [Note] Ignoring --secure-file-priv value as server is running with --initialize -insecure.
08:23 : 2018-01-10T05:05:46.449075Z 0 [Note] Ignoring --secure-file-priv value as server is running with --bootstrap.

become explicit according to the settings used.

I realise that a message like this won't be seen often but when it is being as clear as you can in the logging should ensure that the user can see exactly what the problem is.

On current 5.7 I see this:

E:\git\mysql-5.7\bld\sql\RelWithDebInfo>mysqld --initialize-insecure --console
2018-01-10T08:42:10.411425Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-01-10T08:42:10.588947Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2018-01-10T08:42:10.591448Z 0 [ERROR] Aborting

Hm. If that's the case that looks fine. I'm sure that the server concerned was not stopping as you show as that's the behaviour I would expect. I'm not sure it's still about to investigate further or provide more details. Given that I guess I'm happy with the behviouar so  I 'll change back to closed. If I can reproduce this (maybe related to my config?) on a current version of 5.7 then I'll re-open this.

Thanks for checking.