MySQL Bugs: #70283: MySQL Workbench wont connect to MySQL server

Bug #70283	MySQL Workbench wont connect to MySQL server
Submitted:	10 Sep 2013 4:57	Modified:	1 May 2014 17:28
Reporter:	Max Mudu	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Workbench	Severity:	S2 (Serious)
Version:	MySQL 5.5.32-0ubuntu0.13.04.1	OS:	Linux (Ubuntu 13.04)
Assigned to:		CPU Architecture:	Any
Tags:	127.0.0.1, innodb, localhost, myisam, MySQL Workbench, root

Description:
I have recently upgraded from Ubuntu 12.04 to 13.04. I have also upgraded MySQL Workbench from 5 to 6.0.7. I could connect to MySQL from the command line using the root user but not using the WB.
From the command line I tried successfully the following commands:
mysql -u root -p -h 127.0.0.1
mysql -u root -p -h localhost
mysql -u root -p
After entering the pwd I could connect.

With WB I could not connect to MySQL using a new connection with the following parameters:

Hostname: 127.0.0.1
Port:3306
Username:root
Password:any password

Hostname: localhost
Port:3306
Username:root
Password:any password

The error I got is: [ERR][ GRTDispatcher]: exception in grt execute_task, continuing: Exception: Access denied for user 'root'@'localhost' (using password: NO)

I then remembered that I had some schemas with MyISAM storage engine and some other schemas with INNODB. The schemas with MyISAM were created using the old MySQL browser and the size of those schemas were quite large. So I decided to remove the schemas with MyISAM storage engine from the command line.
After I removed all the MyISAM schemas I managed successfully to use the WB to connect to MySQL.
I have not being able to recreate the issue again. I have created a new schema with MyISAM and now I am able to connect to MySQL using the WB. Maybe it was the size of the schemas with MyISAM that were too big.
Is there a limit on the size of the databases that WB can connect to MySQL?

How to repeat:
I was not able to recreate this issue after I solved it.

Thank you for the bug report. Are you tried local socket as connection method?. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Hello!

I get the same error:
GRTDispatcher]: exception in grt execute_task, continuing: Exception: Access denied for user 'root'@'localhost' (using password: NO)Launching SQL IDE

Is the second time that this happens to me, I re-installed MySql and after that it worked about two months, now I get it again... should I get another version of MySql Workbench?

Thanks!
Luana

I remember to have too many schemas and the Workbench was not able to cope with all of them.  I had some MYISAM and INNODB schemas.  I removed all the old MYISAM as I was migrating to INNODB and then it worked.  You may want to reduce the number of schema that exists when starting the Workbench.

Please try version 6.0.9 or 6.1.1. Thanks.

Happens with Workbench 6.0.9 for me as well on Mac, however, it still lets me connect successfully.

It's not a nefarious error, but it seems like some kind of "default".

Funny enough, I reset the password for root to nothing and I do not get the error.

This additional connection attempt seems like it should not be in the code.

17:33:12 [INF][     SSH tunnel]: Starting tunnel
17:33:12 [INF][     SSH tunnel]: Existing SSH tunnel not found, opening new one
17:33:12 [INF][     SSH tunnel]: Opening SSH tunnel to poc-mysql3-ep.tops.gdi
17:33:16 [INF][     SSH tunnel]: TunnelManager.wait_connection returned OK
17:33:16 [INF][     SSH tunnel]: SSH tunnel connect executed OK
17:33:16 [ERR][  GRTDispatcher]: exception in grt execute_task, continuing: Exception: Access denied for user 'root'@'127.0.0.1' (using password: NO)

Is sounds like the cmdline client is connecting via socket, while WB is trying to connect to the TCP port, because it can't find the socket path (different defaults). Find out what's the socket path the cmdline client is connecting to (connect with it and then run select @@socket) and use that path to setup a Socket based connection to localhost

Is sounds like the cmdline client is connecting via socket, while WB is trying to connect to the TCP port, because it can't find the socket path (different defaults). Find out what's the socket path the cmdline client is connecting to (connect with it and then run select @@socket) and use that path to setup a Socket based connection to localhost

Please try what Alfredo asked. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".