Bug #84173 mysqld_safe --no-defaults & silently does NOT work any more
Submitted: 13 Dec 2016 8:33 Modified: 15 Feb 2017 1:22
Reporter: Valeriy Kravchuk Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Command-line Clients Severity:S3 (Non-critical)
Version:5.7.17 OS:Fedora (Fedora 23)
Assigned to: Terje Røsten CPU Architecture:Any
Tags: basedir, datadir, missing manual, mysqld_safe, regression

[13 Dec 2016 8:33] Valeriy Kravchuk
Description:
For more than a decade I started test MySQL instances as follows (from their respective basedirs):

bin/mysqld_safe --no-defaults &

This morning, with fresh newly built 5.7.17 it stopped working:

[openxs@fc23 5.7]$ bin/mysqld_safe --no-defaults &
[1] 29236
[openxs@fc23 5.7]$ 2016-12-13T08:16:37.905409Z mysqld_safe Logging to './data/fc23.err'.
2016-12-13T08:16:37.908706Z mysqld_safe Logging to './data/fc23.err'.
2016-12-13T08:16:37.940314Z mysqld_safe Starting mysqld daemon with databases from ./data
2016-12-13T08:16:38.143581Z mysqld_safe mysqld from pid file ./data/fc23.pid ended

[1]+  Done                    bin/mysqld_safe --no-defaults

I checked release notes (https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-17.html) and found a section about incompatible changes in mysqld_safe, that says (among other things):

" Other related changes:

    Initialization scripts that invoke mysqld_safe pass --basedir explicitly."

I tried to pass --basedir, surely:

[openxs@fc23 5.7]$ bin/mysqld_safe --no-defaults --basedir=/home/openxs/dbs/5.7 &
[1] 29317
[openxs@fc23 5.7]$ 2016-12-13T08:17:04.841922Z mysqld_safe Logging to './data/fc23.err'.
2016-12-13T08:17:04.845394Z mysqld_safe Logging to './data/fc23.err'.
2016-12-13T08:17:04.878397Z mysqld_safe Starting mysqld daemon with databases from ./data
2016-12-13T08:17:05.084794Z mysqld_safe mysqld from pid file ./data/fc23.pid ended

[1]+  Done                    bin/mysqld_safe --no-defaults --basedir=/home/openxs/dbs/5.7

No help. Then I passed --datadir as well (used to be needed for --initialize, somehow I know it):

[openxs@fc23 5.7]$ bin/mysqld_safe --no-defaults --basedir=/home/openxs/dbs/5.7 --datadir=/home/openxs/dbs/5.7/data &
[1] 29410
[openxs@fc23 5.7]$ 2016-12-13T08:17:24.051919Z mysqld_safe Logging to '/home/openxs/dbs/5.7/data/fc23.err'.
2016-12-13T08:17:24.055443Z mysqld_safe Logging to '/home/openxs/dbs/5.7/data/fc23.err'.
2016-12-13T08:17:24.088511Z mysqld_safe Starting mysqld daemon with databases from /home/openxs/dbs/5.7/data

[openxs@fc23 5.7]$ bin/mysql -uroot -e'select version();'
+-----------+
| version() |
+-----------+
| 5.7.17    |
+-----------+

This time it worked.

Now, tell me where in http://dev.mysql.com/doc/refman/5.7/en/mysqld-safe.html one may find that both --basedir and --datadir are mandatory settings since 5.7.17? It was not tyhe case wioth 5.7.16, and had never ever been the case in MySQL history!

How to repeat:
Build MySQL 5.7.17 from sources, install it, initialize data directory (if needed, in case it's not upgrade) and then try to start it from the basedir as it was usual for many years:

bin/mysqld_safe --no-defaults &

Enjoy the results, including the detailed messages in the error log...

Suggested fix:
1. If both --basedir and --datadir options are mandatory now for mysqld_safe script, document them both (as inocmpatible change) as such in the manual and release notes:

http://dev.mysql.com/doc/refman/5.7/en/mysqld-safe.html
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-17.html

2. Make sure the script clearly writes to the error log and/or stderr what is the reason why it can not start the server.
[13 Dec 2016 8:57] Valeriy Kravchuk
This was on recently updated Fedora 23 64-bit box
[13 Dec 2016 9:14] Umesh Shastry
Hello Valeriy,

Thank you for the bug report.

Thanks,
Umesh
[13 Dec 2016 9:16] Umesh Shastry
test results

Attachment: 84173.results (application/octet-stream, text), 4.60 KiB.

[13 Dec 2016 9:17] Umesh Shastry
Imho - this sounds like doc bug to me after reading https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-17.html
[13 Dec 2016 10:49] Terje Røsten
Posted by developer:
 
I think root cause is that "mysqld_safe ignores the current working directory"; 
from release notes:
  http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-17.html 

Workaround: use absolute path to datadir, for example:

$ bin/mysqld_safe --no-defaults --datadir=$(pwd)/data & 

Or even better: stop using leagcy mysql_safe script and use the daemonize option[1]:

$ bin/mysqld  --no-defaults --daemonize --log-error --datadir=$(pwd)/data

(no trailing & neeeded)

[1]: http://dev.mysql.com/doc/refman/5.7/en/server-options.html#option_mysqld_daemonize
[13 Dec 2016 13:35] Peter Laursen
To me it looks like this page http://dev.mysql.com/doc/refman/5.7/en/mysqld-safe.html also needs an update where it says 

Because mysqld_safe tries to find the server and databases relative to its own working directory, you can install a binary distribution of MySQL anywhere, as long as you run mysqld_safe from the MySQL installation directory:

shell> cd mysql_installation_directory
shell> bin/mysqld_safe &

-- Peter
-- not a MySQL/Oracle person
[25 Dec 2016 10:36] Terje Røsten
Hi Valerii!

$ bin/mysqld_safe --no-defaults &

not working is regression we hope to fix in next batch of releases, sorry for the trouble.
[31 Jan 2017 11:37] Valeriy Kravchuk
Version 5.5.54 is also affected.
[15 Feb 2017 1:22] Paul Dubois
Posted by developer:
 
Noted in 5.5.55, 5.6.36, 5.7.18, 8.0.1 changelogs.

mysqld_safe --no-defaults did not work (inadvertent consequence of an
earlier bug fix).