Description:
mysqld --bootstrap is of course called from mysql_install_db
And normally, it would only be run on a new installation, so there's no MySQL Server running.
However, if someone (or something!) does start the script, mysqld will start.
Normally multiple servers can't run on the same datadir because they'll try to bind to the same IP port.
However, --bootstrap won't bind to an IP port, so it can. And thus it can touch any data and logfiles while a server is running. This is mostly harmless because of what it does and how it does it (as far as I can tell), except that it does initialise its binlog subsystem.
So, say the running MySQL server is working with binlog.000007
mysqld --bootstrap will create binlog.000008 (as root:root), do its other stuff, and exits. It may also write binlog.index but not sure and it's probably kept open by the running server anyway...
What will the running server do next, when binlog 7 becomes full, on FLUSH LOGS, or server restart?
Will the running server overwrite the binlog.index? or append?
This and many more potential race conditions... it's a messy situation.
The running server later complains about not being able to start binlog 8 (since it's owned by root, etc)
--bootstrap just shouldn't initialise binlog, then there wouldn't be a issue.
Note that cPanel runs mysql_install_db in its automatic upgrade scripts, and it behaves exactly as described above. It then chowns the binlog files to mysql:mysql which does is a hack, also there's still a brief moment where the logfile has the wrong permissions, and mysqld may still encounter other race conditions by the mysql --bootstrap just adding a binlog file independently.
How to repeat:
start a mysql server
run mysql_install_db (as root, like normal)
See the new binlog file get created, with ownership/group root!
Suggested fix:
--bootstrap mode should not initialise binlog subsystem, or anything else not needed for bootstrap functionality (installation of the mysql system db tables).
