MySQL Bugs: #49766: my.cnf configuration hanging, erroring, ...

Bug #49766	my.cnf configuration hanging, erroring, ...
Submitted:	17 Dec 2009 11:11	Modified:	16 Feb 2010 11:23
Reporter:	Susanne Ebrecht	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S1 (Critical)
Version:		OS:	Any
Assigned to:	Maksym Yehorov	CPU Architecture:	Any

Description:
1) Get a default installed server
Default installation is without my.cnf
So there should not be a my.cnf in /etc/mysql or somewhere else

2) start sever

3) Open Workbench
4) New Server Instance
5) localhost
6) choose a package
7) choose a connection or configure one if you don't have a connection configured already
8) Press next more often

Location of and section in the MySQL configure file

Read the text ....

You don't have a my.cnf yet ... so try to empty the field ...

Press next

A Window will pop up with one-way-road sign and the message:

Empty path
The path to the configuration must not be empty

Consider, MySQL server will look for my.cnf by automatism anyway.

So it is not needed for starting the server.

But of course it is needed for setting configuration variables. So Workbench needs to know where to store the file in future.

$ libexec/mysqld --verbose --help | less

Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /home/miracee/mysql51bzr/etc/my.cnf ~/.my.cnf

Let's try to set here ~/.my.cnf

Press Check Path ... config file couldn't found ... ok that is right because config file not exist already.

All works fine ...

Now try to setup a my.cnf ... try to configure your first value:

1) double click your new instance in server administration
2) click on configuration

Just configure general log or so

Enter super user password ....

What the hell is the super user password?

Which super user is meant here? Why do you need the password from MySQL user root or whoever else I granted as super user?

Ahhh you didn't mean super user here you meant system root/administrator.

But why the hell do you need my system user root pw for writing into my home?

heck if we can write to file ~/.my.cnf
Exception OSError: OSError(9, 'Bad file descriptor') in <bound method spawn.__del__ of <pexpect.spawn object at 0x3ab47d0>> ignored
Pipe from sudo is closed. Nothing we can do

Give it another try ....

Change instance configuration to /etc/mysql/my.cnf

again try to set general log

Check if we can write to file /etc/mysql/my.cnf
Pipe from sudo is closed. Nothing we can do
Pipe from sudo is closed. Nothing we can do
read_mysql_cfg_file /etc/mysql/my.cnf

and here it is hanging ....

No file will be created.

Additionally, I wanted to look if the created file belongs to the correct user and not to root but I couldn't test this.

How to repeat:
See above

Suggested fix:
This looks like all this configure file stuff needs a deeper check and overwork.

The bugs related to saving of my.cnf are fixed.
- Fixed saving to a non-existent file.
- Reworked detection of writing possibilities/permissions
- Discard button reloads config from file, also file is re-read after save
And there can always be race condition between events when you press save button and someone writes to config file, so having always reloaded file is a kind of illusion, as we can not guarantee atomicity of editing by sane means.

Bug #50317 is set as duplicate of this bug here.

listed fixes confirmed in repository.

An entry has been added to the 5.2.16 changelog:

For a default MySQL Server installation, no my.ini or my.cnf file is created. This proved problematic when creating a server instance in MySQL Workbench, as the Create a new server instance wizard expected a configuration file to be specified. If the path to the configuration file was left blank, a model error dialog was displayed by the wizard. If alternatively, one of the standard locations for the configuration file was entered, problems arose when an attempt was made to subsequently change configuration values in the configuration section of the Admin screen. The problems included MySQL Workbench hanging, and repetitive requests for a 'super user' password.