|
|
|
Yes, I solved this. As far as I know this can be cause by a DBI/DBD
problem or a MySQL
misconfiguration of sockets or permissions (permissions give you the
same problem if they
are not configured properly).
Here's the whole discussion I had on the forum:
==============================================================================================
Another posibility:
I had the same problem -as far as you describe-. Try to connect to database
with "mysql -hHOST_IP" and with "mysql -hlocalhost".
if -hHOST_IP works and -hlocalhost doesn't it surely is the same.
MySQL works both with TCP/IP and UNIX sockets. While connecting with
-hHOST_IP you are connecting through TCP/IP but with
-hlocalhost, or DBI, you're trying to connect through UNIX sockets
(someone please correct me, I not very wise on this).
The mysql.sock file performs some kind of esencial function to the client
to know if there's a server, if it exist, then connects (a kinda
PID thing if I can say).
Also, there's a mysql compilation directive when running configure
(./configure --with-unix-socket-path=<somepath>/mysql.sock).
I'm not quite sure about this as I've downloaded the binary distribution
but maybe that's why mysql pointed to /tmp/mysql.sock, thus
when DBI looked for mysql.sock at /var/lib/mysql couldn't find it.
I don't know how to change this setting on mysql nor DBI, so I kinda
patched my own solution, that I don't know if it is "politically" correct
nor safe, but -at least by now- functional...
My solution was to make a soft link to mysql.sock (ln -s /tmp/mysql.sock
/var/lib/mysql/mysql.sock). I really doubted that that would
work, but it did...
I also learned this time that linux' soft links are really beyond from
the always-comparition-start-point-for-windows-users .lnk files.
The link made with ln returns a false when checking file of the link
and the linked file doesn't exist (while if you ls the directory...
there's the link!!!). really neat.
(let me learn some english too: is the last posesive apostrophe well placed? how's the possesive of "linux"?)
hope this -finally- helped.
Marcel Montes wrote:
Hmmm....
run mysql with:
<mysql_path>/bin/safe_mysqld --skip-grant-tables --user=mysql
&
(if the daemon user is mysql... if not change for whatever it
is).
Try again and if it works then is a mysql permissions problem.
Heinz Wittenbecher wrote:
> RH7 / latest MySQL rpm from mysql site. Perl 5.6.0
>
> DBI connect failed: Can't connect to local MySQL server
through socket
> '/var/lib/mysql/mysql.sock' (111)
>
> Have redone CPAN DBI and DBD installs. perl reports that both
are up to
> date. I can access the data via mysql and webmin/sql.
>
> Any ideas?
>
> What's worse is that on another machine I have it all working.
Even tried a
> tar from the working one and get same error.
> Permissions on /var/lib/mysql/mysql.sock same on both machines.
>
> Any pointers greatly appreciated.
>
> Heinz
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@www.minivend.com
> http://www.minivend.com/mailman/listinfo/interchange-users
================================================================================================
Also, you got to keep this in mind. I don't know if minivend creates
tables at makecat. (Never seen so)
As far as I know, tables are generated when you restart interchange
$ <path-to-interchange>/bin/interchange restart
or
$ <path-to-interchange>/bin/interchange -r
Also, I don't know if when the database is created, permissions are
granted on that particular database for
the interchange DBI user.
To do so:
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER
ON [DATABASE].* TO [USERNAME]@localhost IDENTIFIED BY '[PASSWORD]';
If there's still problems and you want to know if it IS a permission
problems, try skipping grant tables (as it says before).
Good Luck
--
Marcel Montes [marcel(at)multimake(dot)com] - Programmer
"If our brain were so simple that we could understand it,
we would be so stupid that we couldn't do so"
-------------------------- EOF ----------------------------