alien maybe you have an idea ?

CC: (none) => alien

afaict it looks like libmysqlcppconn.so.5 is being searched, but i guess since libmysqlcppconn6 is being installed that a libmysqlcppconn.so.6 is there instead?

i don't know, but the user could try to rebuild the src.rpm for mysql-workbench to see if this would alleviate the problem.

i tried rebuilding it, to see if it worked, but was unsuccessful...

maybe we should drop this package, if it doesn't work...

I also had this bug and updating to mysql-workbench-5.2.36-2.mga2 fixes the problem.

Jeff

CC: (none) => jalaramie

closing then, thanks

Status: NEW => RESOLVED
Resolution: (none) => FIXED

*** Bug 5595 has been marked as a duplicate of this bug. ***

CC: (none) => etiennedau-site

> yep maybe

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

sorry should be 
>maybe we should drop this package, if it doesn't work...
yep maybe

perhaps first ask him if he has 5.2.36.2.mga2 ...

Yes I have the 5.2.36.2.mga2 x86_64

(In reply to comment #4)
> I also had this bug and updating to mysql-workbench-5.2.36-2.mga2 fixes the
> problem.
> 
> Jeff

could you retry with beta3? to see if etienne 's problem is limited to himself or that i's something larger.

etienne, since the MCC services doesn't yet work on beta3 (it will on RC), can you check with commandline systemctl mysqld.service start and status if everything works nicely?

perhaps check with 'mysql' cli client to see if it all works?

(In reply to comment #11)
> (In reply to comment #4)
> > I also had this bug and updating to mysql-workbench-5.2.36-2.mga2 fixes the
> > problem.
> > 
> > Jeff
> 
> could you retry with beta3? to see if etienne 's problem is limited to himself
> or that i's something larger.
> 
> etienne, since the MCC services doesn't yet work on beta3 (it will on RC), can
> you check with commandline systemctl mysqld.service start and status if
> everything works nicely?
> 
> perhaps check with 'mysql' cli client to see if it all works?

Short answer: It no longer works for me either.

Long answer: There are a few "gotchas" that make this harder than it needs to be.

1 - mysql is now provided by the mysql-MariaDB package. Make sure MariaDB is installed and running. Don't be confused if ps shows mysqld already running. It appears this is a daemon run by akonadi and is not the standard database daemon. Don't forget to set the root password before trying to connect.

2 - Connecting to "localhost" should work ok, but connecting to the local daemon by another host name will probably fail since mga assigns 127.0.0.1 to all local hostnames and it won't resolve correctly.

3 - The default my.cnf disables tcp-ip connections which is what mysql-workbench uses by default. Changing my.cnf to allow tcp-ip or changing mysql-workbench to use "Local Socket/Pipe" should fix this.

I got MariaDB running and I can connect with the mysql CLI client, but mysql-workbench doesn't connect. Unfortunately I don't have time right now to do any more research on this.

(In reply to comment #11)
> (In reply to comment #4)
> > I also had this bug and updating to mysql-workbench-5.2.36-2.mga2 fixes the
> > problem.
> > 
> > Jeff
> 
> could you retry with beta3? to see if etienne 's problem is limited to himself
> or that i's something larger.
> 
> etienne, since the MCC services doesn't yet work on beta3 (it will on RC), can
> you check with commandline systemctl mysqld.service start and status if
> everything works nicely?
> 
> perhaps check with 'mysql' cli client to see if it all works?

[root@localhost ~]# systemctl mysqld.service start
Unknown operation mysqld.service
[root@localhost ~]# /etc/rc.d/init.d/mysqld start
Starting mysqld (via systemctl):                                [  OK  ]

(In reply to comment #11)
> (In reply to comment #4)
> > I also had this bug and updating to mysql-workbench-5.2.36-2.mga2 fixes the
> > problem.
> > 
> > Jeff
> 
> could you retry with beta3? to see if etienne 's problem is limited to himself
> or that i's something larger.

I resolved this by removing the "skip-networking" parameter from /etc/my.cnf. It now connects using both tcp-ip and the local socket. I would be interested to know why this setting blocks the local socket connection. I don't think it used to or should block it.

Jeff

I remove this parameter too and it's ok now

so, in short, mysql-workbench connects to the network socket and not the unix socket?

or is mysql completely nonworking with this option?

if so, are these new installs?

(In reply to comment #16)
> so, in short, mysql-workbench connects to the network socket and not the unix
> socket?
> 
> or is mysql completely nonworking with this option?
> 
> if so, are these new installs?

With skip-networking enabled the mysql CLI tool can connect but mysql-workbench can't connect by either method.

With skip-networking disabled mysql and mysql-workbench can connect by either method.

For some reason skip-networking disables mysql-workbench's access to the local socket when it shouldn't. I don't know which package is at fault.

My version of mysql-workbench hasn't changed since I first installed mga2 on this box a couple weeks ago, but MariaDB was updated last night to mariadb-5.5.23-3.mga2 and updated at least once before that.

Jeff

to be completely sure,

can you try to still add skip-networking, then configure mysql-workbench to connect on the socket, then do a tcpdump on the mysql port to see if mysqlbench is still trying network...

(In reply to comment #17)
> (In reply to comment #16)
> > so, in short, mysql-workbench connects to the network socket and not the unix
> > socket?
> > 
> > or is mysql completely nonworking with this option?
> > 
> > if so, are these new installs?
> 
> With skip-networking enabled the mysql CLI tool can connect but mysql-workbench
> can't connect by either method.
> 
> With skip-networking disabled mysql and mysql-workbench can connect by either
> method.
> 
> For some reason skip-networking disables mysql-workbench's access to the local
> socket when it shouldn't. I don't know which package is at fault.
> 
> My version of mysql-workbench hasn't changed since I first installed mga2 on
> this box a couple weeks ago, but MariaDB was updated last night to
> mariadb-5.5.23-3.mga2 and updated at least once before that.
> 
> Jeff

mariadb asked if you can check if workbench is using the correct socket path (check with lsof |grep workbench)

(In reply to comment #19)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > so, in short, mysql-workbench connects to the network socket and not the unix
> > > socket?
> > > 
> > > or is mysql completely nonworking with this option?
> > > 
> > > if so, are these new installs?
> > 
> > With skip-networking enabled the mysql CLI tool can connect but mysql-workbench
> > can't connect by either method.
> > 
> > With skip-networking disabled mysql and mysql-workbench can connect by either
> > method.
> > 
> > For some reason skip-networking disables mysql-workbench's access to the local
> > socket when it shouldn't. I don't know which package is at fault.
> > 
> > My version of mysql-workbench hasn't changed since I first installed mga2 on
> > this box a couple weeks ago, but MariaDB was updated last night to
> > mariadb-5.5.23-3.mga2 and updated at least once before that.
> > 
> > Jeff
> 
> mariadb asked if you can check if workbench is using the correct socket path
> (check with lsof |grep workbench)

I'm not familiar with lsof so I don't know if this helps, but here's what I got:

[root@JeffDesk jalaramie]# lsof |grep workbench
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /run/user/jalaramie/gvfs
      Output information may be incomplete.
mysql-wor  1502        jalaramie  255r      REG                8,2       394     549836 /usr/bin/mysql-workbench
mysql-wor  1505        jalaramie  txt       REG                8,2  10831096     549932 /usr/bin/mysql-workbench-bin
mysql-wor  1505        jalaramie  mem       REG                8,2   1975408     576667 /usr/lib64/mysql-workbench/plugins/db.mysql.wbp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2   1142880     576664 /usr/lib64/mysql-workbench/plugins/db.mysql.editors.wbp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    393208     576670 /usr/lib64/mysql-workbench/plugins/wb.model.editors.wbp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    611856     576661 /usr/lib64/mysql-workbench/plugins/db.mysql.diff.reporting.wbp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    159288     576676 /usr/lib64/mysql-workbench/plugins/wb.printing.wbp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    200208     576673 /usr/lib64/mysql-workbench/plugins/wb.model.snippets.wbp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2     18864     576658 /usr/lib64/mysql-workbench/plugins/db.checks.wbp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2     31288     576645 /usr/lib64/mysql-workbench/modules/dbutils.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    121992     576636 /usr/lib64/mysql-workbench/modules/db.mysql.query.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2   2977984     576642 /usr/lib64/mysql-workbench/modules/db.mysql.sqlparser.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2     51984     576648 /usr/lib64/mysql-workbench/modules/forms.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    365040     576651 /usr/lib64/mysql-workbench/modules/wb.model.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    561608     576633 /usr/lib64/mysql-workbench/modules/db.mysql.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2     43984     576639 /usr/lib64/mysql-workbench/modules/db.mysql.sqlide.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    484536     576654 /usr/lib64/mysql-workbench/modules/wb.mysql.import.grt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    175656     564039 /usr/lib64/mysql-workbench/libvsqlitepp.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    187888     563999 /usr/lib64/mysql-workbench/libmdcanvasgtk.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2   1179192     562055 /usr/lib64/mysql-workbench/libgrt.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    193272     564041 /usr/lib64/mysql-workbench/libwbbase.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2     84872     550178 /usr/lib64/mysql-workbench/libcdbc.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2   1069752     563341 /usr/lib64/mysql-workbench/libmdcanvas.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2   7442472     576624 /usr/lib64/mysql-workbench/libwbpublic.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2   2101864     576626 /usr/lib64/mysql-workbench/libwbscintilla.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    490528     564035 /usr/lib64/mysql-workbench/libsqlide.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2    498224     562818 /usr/lib64/mysql-workbench/liblinux_utilities.so.0.0.0
mysql-wor  1505        jalaramie  mem       REG                8,2   2209560     564033 /usr/lib64/mysql-workbench/libmforms.so.0.0.0
mysql-wor  1505  1512  jalaramie  txt       REG                8,2  10831096     549932 /usr/bin/mysql-workbench-bin
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   1975408     576667 /usr/lib64/mysql-workbench/plugins/db.mysql.wbp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   1142880     576664 /usr/lib64/mysql-workbench/plugins/db.mysql.editors.wbp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    393208     576670 /usr/lib64/mysql-workbench/plugins/wb.model.editors.wbp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    611856     576661 /usr/lib64/mysql-workbench/plugins/db.mysql.diff.reporting.wbp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    159288     576676 /usr/lib64/mysql-workbench/plugins/wb.printing.wbp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    200208     576673 /usr/lib64/mysql-workbench/plugins/wb.model.snippets.wbp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2     18864     576658 /usr/lib64/mysql-workbench/plugins/db.checks.wbp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2     31288     576645 /usr/lib64/mysql-workbench/modules/dbutils.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    121992     576636 /usr/lib64/mysql-workbench/modules/db.mysql.query.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   2977984     576642 /usr/lib64/mysql-workbench/modules/db.mysql.sqlparser.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2     51984     576648 /usr/lib64/mysql-workbench/modules/forms.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    365040     576651 /usr/lib64/mysql-workbench/modules/wb.model.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    561608     576633 /usr/lib64/mysql-workbench/modules/db.mysql.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2     43984     576639 /usr/lib64/mysql-workbench/modules/db.mysql.sqlide.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    484536     576654 /usr/lib64/mysql-workbench/modules/wb.mysql.import.grt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    175656     564039 /usr/lib64/mysql-workbench/libvsqlitepp.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    187888     563999 /usr/lib64/mysql-workbench/libmdcanvasgtk.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   1179192     562055 /usr/lib64/mysql-workbench/libgrt.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    193272     564041 /usr/lib64/mysql-workbench/libwbbase.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2     84872     550178 /usr/lib64/mysql-workbench/libcdbc.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   1069752     563341 /usr/lib64/mysql-workbench/libmdcanvas.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   7442472     576624 /usr/lib64/mysql-workbench/libwbpublic.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   2101864     576626 /usr/lib64/mysql-workbench/libwbscintilla.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    490528     564035 /usr/lib64/mysql-workbench/libsqlide.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2    498224     562818 /usr/lib64/mysql-workbench/liblinux_utilities.so.0.0.0
mysql-wor  1505  1512  jalaramie  mem       REG                8,2   2209560     564033 /usr/lib64/mysql-workbench/libmforms.so.0.0.0

hmm, i don't see the socket anywhere...

lsof lists open files in use by applications

for this to work you'll have to have workbench configured to use the socket file.

perhaps you can try to lsof | grep sock | grep mysql to see if it's there but maybe used by a library instead?

(In reply to comment #21)
> hmm, i don't see the socket anywhere...
> 
> lsof lists open files in use by applications
> 
> for this to work you'll have to have workbench configured to use the socket
> file.
> 
> perhaps you can try to lsof | grep sock | grep mysql to see if it's there but
> maybe used by a library instead?

That command returns about a million results that look like this:

mysqld    24161 24196      mysql   15u     unix 0xffff880065732080       0t0    3633228 /var/lib/mysql/mysql.sock
mysqld    24161 24197      mysql   15u     unix 0xffff880065732080       0t0    3633228 /var/lib/mysql/mysql.sock
mysqld    24161 24198      mysql   15u     unix 0xffff880065732080       0t0    3633228 /var/lib/mysql/mysql.sock
mysqld    24161 24207      mysql   15u     unix 0xffff880065732080       0t0    3633228 /var/lib/mysql/mysql.sock
mysqld    24161 24208      mysql   15u     unix 0xffff880065732080       0t0    3633228 /var/lib/mysql/mysql.sock

I don't know how to narrow this down to a usable result and how you could tell the difference between the connection from akonadi and from mysql-workbench.

"lsof | grep workbench | grep sock" produces no results.

and what about

"lsof | grep sock | grep mysql-wor"

(i saw that the output of the process string stops at 8 chars)

or even 

"lsof | grep sock | grep mysql | grep -v mysqld" ?

(In reply to comment #23)
> and what about
> 
> "lsof | grep sock | grep mysql-wor"
> 
> (i saw that the output of the process string stops at 8 chars)

I tried these and didn't get anything useful. After thinking about this I realized it doesn't really matter what the default socket file is since you can change it.

I tried setting it manually to var/lib/mysql/mysql.sock and the results were the same. It would connect if skip-networking was disabled but not if skip-networking was enabled.

So then I set it manually to "var/lib/mysql/foo.bar" and it still connected. It seems that it ignores the parameter altogether.

Since we didn't find a socket file with lsof, since the connection depends on tcp-ip being enabled in my.cnf, and since it connects no matter what the socket file is, my conclusion is that mysql-workbench is only using tcp-ip to connect no matter what the connection settings are. I'm pretty sure this is a mysql-workbench bug.

that was what i figured as well...

There may be another mysql-workbench bug. I tested it last night just before I added my comment here. I just noticed that mysql-workbench is still running even though I closed the GUIs last night:

[root@JeffDesk jalaramie]# ps -A | grep mysql-workbench
 1502 ?        00:00:00 mysql-workbench
 1505 ?        00:00:01 mysql-workbench
 2472 ?        00:00:00 mysql-workbench
 2473 ?        00:00:10 mysql-workbench
19775 ?        00:00:00 mysql-workbench
19776 ?        00:00:09 mysql-workbench

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

I hope I'm not confusing two issues, but I see the same problem with MySQL Workbench.

I run MariaDB with the 'skip-networking' option turned on. If I try to connect using MySQL Workbench via the socket '/var/lib/mysql/mysql.sock', I see the following message:

Error occured: Unknown MySQL server host '/var/lib/mysql/mysql.sock' (0)

However if I change the socket name to '/var/lib/mysql/foo.sock' the message changes to:

Error occured: Can't connect to MySQL server on '127.0.0.1' (111)

If I enable networking in my.cnf, I see the same error in the first case, but in the second I can connect (presumably via TCP/IP).

I wondered whether the workbench software was seeing an unexpected response when connecting via the socket (MariaDB instead of MySQL as the server name maybe?) but not via networking.

CC: (none) => mg

upstream tells me this might be possible.

i guess some developer could try to find where MySQL is being expected and loosen that check or something.

perhaps you could try to use the 'mysql' command in a terminal to check if that works over a socket connection.

upstream tells me that it might be related to mysql-connector-c++ since that's in their experience not something that people have been actively developing on

you could try rebuilding that from a newer version and see if that helps

(In reply to comment #31)
> perhaps you could try to use the 'mysql' command in a terminal to check if that
> works over a socket connection.

Yes it does, also PHP connects locally via socket.

mariadb people pointed out to me that only mysql-workbench is using mysql-connector-c++ afatk.

so maybe it's there

I'm still not clear currently which is the problem. I can connect in both cases:

1. If skip-networking is commented and the configured connection is configured to use TCP/IP, the connection works.

2. If skip-networking is not commented and the configured connection is configured to use *local socket/pipe* and I use /var/lib/mysql/mysql.sock, the connection also works.

For what I have understood from some of the comments, it seems that some of the people testing this when enabling skip-networking, they have forgotten to change the type of connection from TCP/IP to local socket/pipe and specify the correct socket. That seems to be the reason some say that mysql-workbench seems to still try to connect via TCP/IP after they have enabled skip-networking (which means no TCP/IP connection is available) and want to connect using local sockets.

Also I never get nor in the wizard or in the text console the initial report error about libmysqlcppconn.so.5: can not open shared object file. No such file or
directory").

so, in short? there is no bug, it's a feature? or ...?

For me, there's no bug, it's how it is supposed to be. If you are using local sockets, then your connection configured in workbench should be configured to use local sockets, and if you are using TCP connections, then you need to modify your workbench connection to use TCP, don't expect this to happen automatically.

(In reply to comment #36)
> so, in short? there is no bug, it's a feature? or ...?

There was a bug but it was fixed for me by updating to mysql-workbench-5.2.36-2.mga2. I haven't had problems since, so I think the problems people are having are configuration issues as described by Jean Luis Baptiste. Unless someone else can verify that it's still broken (after proper configuration), I think this can be closed.

Jeff

Latest version 5.2.44 of mysql-workbench is available on cauldron, for me the issue is fixed, can the bug reporter test too ?

Also yesterday an update for mga 2 with version mysal-workbench-5.2.36-2.1 was pushed, please test this too.

Ping ?

if the reporter doesn't react, we should close this one and he can reopen if necessary.

I just tested mysql-workbench on fresh Mageia 2 32-bit installation. "Crate new server instance profile" wizard is working ok.

Status changed to FIXED.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED