Bug #65312 MySQL Workbench: Start/Stop server not working
Submitted: 14 May 2012 18:24 Modified: 16 May 2012 4:04
Reporter: Craig Arno Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Workbench: Administration Severity:S3 (Non-critical)
Version:MySQL Workbench CE 5.2.34 7780 OS:Linux (OpenSUSE 12.1 x64 KDE)
Assigned to: CPU Architecture:Any
Tags: workbench administration server start stop

[14 May 2012 18:24] Craig Arno
Description:
MySQL Database on both systems appears to be working when checked through LibreOffice Base JDBC.  My "test" database can be accessed on both my machines by both machines; Server(pluto), Workstation(neptune).

On my Server machine, Workbench is misbehaving with regard to Admin-MANAGEMENT-Startup/Shutdown functionality. On my Workstation machine, Workbench is working correctly.  Both are using KDE.  The only difference I can find so far is one additional process running on my Workstation machine.  I know nothing about databases (newbie stage), but have extensive computer/networking skills.  My question is, how to make MySQL-Workbench work correctly on my server(pluto) machine?

Diagnostic data follows:

neptune:/var/log/mysql # uname -a
Linux neptune 3.1.10-1.9-desktop #1 SMP PREEMPT Thu Apr 5 18:48:38 UTC 2012 (4a97ec8) x86_64 x86_64 x86_64 GNU/Linux
neptune:/var/log/mysql # mysqld --version
mysqld  Ver 5.5.16-log for Linux on x86_64 (Source distribution)
neptune:/var/log/mysql # mysql-workbench --version
** Message: Gnome keyring daemon seems to not be available. Stored passwords will be lost once quit
MySQL Workbench CE 5.2.34 7780

pluto:/var/log/mysql # uname -a
Linux pluto 3.1.10-1.9-desktop #1 SMP PREEMPT Thu Apr 5 18:48:38 UTC 2012 (4a97ec8) x86_64 x86_64 x86_64 GNU/Linux
pluto:/var/log/mysql # mysqld --version
mysqld  Ver 5.5.16-log for Linux on x86_64 (Source distribution)
pluto:/var/log/mysql # mysql-workbench --version
** Message: Gnome keyring daemon seems to not be available. Stored passwords will be lost once quit
MySQL Workbench CE 5.2.34 7780

On my Server machine (misbehaving):
----------------------------------
MySQL Workbench [Admin (localhost)-Startup / Shutdown] reports:
2012-05-14 10:29:02 - Checked server status: Server is stopped.

Server# /etc/init.d/mysql status
redirecting to systemctl
mysql.service - LSB: Start the MySQL database server
          Loaded: loaded (/etc/init.d/mysql)
          Active: failed since Mon, 14 May 2012 08:40:40 -0700; 1h 50min ago
         Process: 16566 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
         Process: 20885 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/mysql.service

Server# ps -C mysqld u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql    22088  0.0  0.4 723780 39972 pts/0    Sl   08:46   0:02 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysql/mysqld.log --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql.sock --port=3306

/var/log/mysql/mysqld.log looks "normal" to me:
120514 08:46:42 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120514  8:46:42 InnoDB: The InnoDB memory heap is disabled
120514  8:46:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120514  8:46:42 InnoDB: Compressed tables use zlib 1.2.5
120514  8:46:43 InnoDB: Initializing buffer pool, size = 128.0M
120514  8:46:43 InnoDB: Completed initialization of buffer pool
120514  8:46:43 InnoDB: highest supported file format is Barracuda.
120514  8:46:43  InnoDB: Waiting for the background threads to start
120514  8:46:44 InnoDB: 1.1.8 started; log sequence number 1626846
120514  8:46:44 [Note] Event Scheduler: Loaded 0 events
120514  8:46:44 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.16-log'  socket: '/var/run/mysql/mysql.sock'  port: 3306  Source distribution

On my Workstation machine (working correctly):
---------------------------------------------
MySQL Workbench [Admin (Neptune)-Startup / Shutdown] reports:
2012-05-14 10:41:55 - Checked server status: Server is running.

Workstation# /etc/init.d/mysql status
redirecting to systemctl
mysql.service - LSB: Start the MySQL database server
          Loaded: loaded (/etc/init.d/mysql)
          Active: active (running) since Mon, 14 May 2012 08:51:44 -0700; 1h 51min ago
         Process: 22264 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
         Process: 23618 ExecStart=/etc/init.d/mysql start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/mysql.service
                  ├ 23668 /bin/sh /usr/bin/mysqld_safe --mysqld=mysqld --user=mysql --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql....
                  └ 23993 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/l...

Workstation# ps -C mysqld u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
craig     2403  0.0  0.3 1839132 26820 ?       Sl   May06   4:39 /usr/sbin/mysqld --defaults-file=/local/craig/.local/share/akonadi//mysql.conf --datadir=/local/craig/.local/share/akonadi/db_data/ --socket=/local/craig/.local/share/akonadi/socket-neptune/mysql.socket
mysql    23993  0.0  0.5 723780 42852 ?        Sl   08:51   0:04 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/var/log/mysql/mysqld.log --pid-file=/var/run/mysql/mysqld.pid --socket=/var/run/mysql/mysql.sock --port=3306

/var/log/mysql/mysqld.log startup also looks "normal" to me:
120514 10:52:49 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120514 10:52:49 InnoDB: The InnoDB memory heap is disabled
120514 10:52:49 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120514 10:52:49 InnoDB: Compressed tables use zlib 1.2.5
120514 10:52:49 InnoDB: Initializing buffer pool, size = 128.0M
120514 10:52:49 InnoDB: Completed initialization of buffer pool
120514 10:52:49 InnoDB: highest supported file format is Barracuda.
120514 10:52:49  InnoDB: Waiting for the background threads to start
120514 10:52:50 InnoDB: 1.1.8 started; log sequence number 1626846
120514 10:52:50 [Note] Event Scheduler: Loaded 0 events
120514 10:52:50 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.16-log'  socket: '/var/run/mysql/mysql.sock'  port: 3306  Source distribution

How to repeat:
unknown.

Suggested fix:
none.
[14 May 2012 20:55] MySQL Verification Team
Pleas check with new version 5.2.39. Thanks.
[15 May 2012 2:16] Craig Arno
Problem solved on my system with the following versions:

pluto:/var/log/mysql # mysql-workbench --version
** Message: Gnome keyring daemon seems to not be available. Stored passwords will be lost once quit
MySQL Workbench CE 5.2.34 7780
pluto:/var/log/mysql # mysqld --version
mysqld  Ver 5.5.23-log for Linux on x86_64 (Source distribution)

For anyone reading and trying to reproduce "success", I performed a YaST "Online Update" to get these versions installed.  I believe the same can be accomplished from the command line with the command "zypper update".

I tried downloading and installing Workbench from Linux Source.  After solving the "libzip" not found and running into "No package 'sigc++-2.0' found" I gave up and tried the system update.  Fortunately OpenSUSE 12.1 updates are ahead of the problems I experienced and this problem is now solved.  MySQL Workbench appears to now be working on both systems.
[15 May 2012 10:58] Valeriy Kravchuk
Looks like this problem was not a result of any bug in MySQL code.
[16 May 2012 4:04] Craig Arno
> Looks like this problem was not a result of any bug in MySQL code.

From my point of view, this is indeterminate.  What I do know is it took a MySQL update from the OpenSUSE 12.1 distribution to fix the issue I experienced.  I don't have enough information to say what in the code or build environment changed to cause this update to make my installation work properly.  For all I know, there may be a code change for MySQL which is in the process of being submitted to the MySQL developers code base.

What I can say is my issue was resolved with an OpenSUSE 12.1 software update which I observed contained changes to my MySQL-OpenSUSE 12.1 x64 installation package.

Since my report is to identify a MySQL fault in an OpenSUSE 12.1 x64 delivered installation, I can say my report can be closed.  I can't say what Novell did to fix this installation, or that Novell MySQL code accurately reflects the current MySQL code base (I hope it does, or soon will, as this is good engineering development practice).