When using the mysql5 +server port, I can't connect locally to mysql using localhost (root). Only 127.0.0.1 and the unix socket works. Any ideas how to fix? A lot of people have this problem on other platforms, as seen here in the comments section here: http://dev.mysql.com/doc/refman/5.0/en/can-not-connect-to-server.html However, none of those suggested fixed worked. I even tried removing the Unix socket line from the port file to see if that worked, but it did not. Any help would be appreciated. Thanks, Karl
On Apr 11, 2007, at 22:32, Karl Timmermann wrote:
When using the mysql5 +server port, I can't connect locally to mysql using localhost (root). Only 127.0.0.1 and the unix socket works. Any ideas how to fix? A lot of people have this problem on other platforms, as seen here in the comments section here:
http://dev.mysql.com/doc/refman/5.0/en/can-not-connect-to-server.html
However, none of those suggested fixed worked. I even tried removing the Unix socket line from the port file to see if that worked, but it did not.
Need more info. What concrete problem do you experience? What error message? Is it about the socket file not existing? If so, does it tell you what path it's looking for the socket file at? If so, does the socket exist there? If so, are its permissions OK? If the socket is not there, why not? Is your mysql server running? What OS version? What processor architecture? What solutions have you already tried? etc. etc. etc.
Hello, Am 12.04.2007 um 07:28 schrieb Ryan Schmidt:
On Apr 11, 2007, at 22:32, Karl Timmermann wrote:
When using the mysql5 +server port, I can't connect locally to mysql using localhost (root). Only 127.0.0.1 and the unix socket works.
Does name resolution work properly? Try to connect using localhost to another server process running locally, e.g. activate personal websharing in the sharing control panel and point your browser to localhost. Does it show the famous "it works" page? If not, stick with that. Try flushcache command on your lookupd. Check with your ethernet config using ifconfig and post results here if you cant deal with that on your own. If it is really mysql-specific, then I dont know about the problem. Bye, Christian
On Apr 12, 2007, at 04:28, Christian Voelker wrote:
On Apr 11, 2007, at 22:32, Karl Timmermann wrote:
When using the mysql5 +server port, I can't connect locally to mysql using localhost (root). Only 127.0.0.1 and the unix socket works.
Does name resolution work properly?
Try to connect using localhost to another server process running locally, e.g. activate personal websharing in the sharing control panel and point your browser to localhost. Does it show the famous "it works" page? If not, stick with that. Try flushcache command on your lookupd. Check with your ethernet config using ifconfig and post results here if you cant deal with that on your own. If it is really mysql-specific, then I dont know about the problem.
Christian, the problem is MySQL-specific. The default hostname to connect to a MySQL server is "localhost", and MySQL special-cases the "localhost" hostname, bypasses the entire network stack, and accesses the local MySQL server's socket file directly. Karl's network probably works fine, since he said it works fine when connecting via the server address 127.0.0.1, for which MySQL does no special-casing, does not go directly to the socket file but rather does use the TCP/ IP stack.
Does name resolution work properly?
Try to connect using localhost to another server process running locally, e.g. activate personal websharing in the sharing control panel and point your browser to localhost. Does it show the famous "it works" page? If not, stick with that. Try flushcache command on your lookupd. Check with your ethernet config using ifconfig and post results here if you cant deal with that on your own. If it is really mysql-specific, then I dont know about the problem.
Christian, the problem is MySQL-specific. The default hostname to connect to a MySQL server is "localhost", and MySQL special-cases the "localhost" hostname, bypasses the entire network stack, and accesses the local MySQL server's socket file directly. Karl's network probably works fine, since he said it works fine when connecting via the server address 127.0.0.1, for which MySQL does no special-casing, does not go directly to the socket file but rather does use the TCP/IP stack.
Correct, localhost works for everything else, such as apache, etc. Is there a configuration setting, or a setting I can set when compiling MySQL to turn off this "localhost to UNIX socket feature". Thanks, Karl
On Apr 12, 2007, at 14:45, Karl Timmermann wrote:
Does name resolution work properly?
Try to connect using localhost to another server process running locally, e.g. activate personal websharing in the sharing control panel and point your browser to localhost. Does it show the famous "it works" page? If not, stick with that. Try flushcache command on your lookupd. Check with your ethernet config using ifconfig and post results here if you cant deal with that on your own. If it is really mysql-specific, then I dont know about the problem.
Christian, the problem is MySQL-specific. The default hostname to connect to a MySQL server is "localhost", and MySQL special-cases the "localhost" hostname, bypasses the entire network stack, and accesses the local MySQL server's socket file directly. Karl's network probably works fine, since he said it works fine when connecting via the server address 127.0.0.1, for which MySQL does no special-casing, does not go directly to the socket file but rather does use the TCP/IP stack.
Correct, localhost works for everything else, such as apache, etc. Is there a configuration setting, or a setting I can set when compiling MySQL to turn off this "localhost to UNIX socket feature".
I don't think so. Why don't we try to fix it instead? Can you provide the answers to the questions I asked earlier? I need more information to begin to help you.
Need more info. What concrete problem do you experience? What error message? Is it about the socket file not existing? If so, does it tell you what path it's looking for the socket file at? If so, does the socket exist there? If so, are its permissions OK? If the socket is not there, why not? Is your mysql server running? What OS version? What processor architecture? What solutions have you already tried? etc. etc. etc.
I can't connect to the mysql server using any tool or program using root@localhost (connecting to "localhost" using the username of "root" and my password). I can however connect if I connect to 127.0.0.1 using root. I have the root user work at any domain. Errors are different depending on which program I use, but basically it says I can't connect. If I try to connect using the socket, it works (not the default socket, but the one that the port specifies). I'm running OS X 10.4.9 on an Intel Core 2 Duo. Basically, localhost is not pointing to the correct socket file. If that could be fixed, it would be fine with me, since all my code and apps point to localhost right now. I don't want to have to add a Unix socket path in every bit of code where I have the connection details. Ideally, it should use TCP/IP when connecting to localhost. If I wanted to use a socket, I would have specified one. I guess the 2 solutions needed (or just one) would be: 1.) How do I make MySQL's localhost mechanism point to the correct socket file if a custom one was specified when compiling mysql via MacPorts, and 2.) how do I turn off this "feature" and let localhost resolve to 127.0.0.1? Thanks again, Karl
On Apr 12, 2007, at 17:20, Karl Timmermann wrote:
Need more info. What concrete problem do you experience? What error message? Is it about the socket file not existing? If so, does it tell you what path it's looking for the socket file at? If so, does the socket exist there? If so, are its permissions OK? If the socket is not there, why not? Is your mysql server running? What OS version? What processor architecture? What solutions have you already tried? etc. etc. etc.
I can't connect to the mysql server using any tool or program using root@localhost (connecting to "localhost" using the username of "root" and my password). I can however connect if I connect to 127.0.0.1 using root. I have the root user work at any domain. Errors are different depending on which program I use, but basically it says I can't connect. If I try to connect using the socket, it works (not the default socket, but the one that the port specifies). I'm running OS X 10.4.9 on an Intel Core 2 Duo.
Basically, localhost is not pointing to the correct socket file. If that could be fixed, it would be fine with me, since all my code and apps point to localhost right now. I don't want to have to add a Unix socket path in every bit of code where I have the connection details. Ideally, it should use TCP/IP when connecting to localhost. If I wanted to use a socket, I would have specified one.
I guess the 2 solutions needed (or just one) would be: 1.) How do I make MySQL's localhost mechanism point to the correct socket file if a custom one was specified when compiling mysql via MacPorts,
The mysql5 portfile uses the configure option --with-unix-socket-path=${prefix}/var/run/${name}/mysqld.sock ${prefix} is usually /opt/local and ${name} is mysql5 so the socket file should be at /opt/local/var/run/mysql5/mysqld.sock That means that the mysql5 server will put its socket there, and the mysql5 client will look for the socket there. Are you running both the MacPorts mysql5 server and the MacPorts mysql5 client? If so, it should just work: $ /opt/local/lib/mysql5/bin/mysql -uroot -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 88 Server version: 5.0.37-log Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> What do you get when you type the above command?
and 2.) how do I turn off this "feature" and let localhost resolve to 127.0.0.1?
That's just the way MySQL works. If you say "localhost", it uses the socket file instead of the network stack. You'll have to speak with the MySQL developers regarding whether it's possible to disable that behavior, although I'm sure the behavior exists for a reason, probably a performance one.
participants (3)
-
Christian Voelker
-
Karl Timmermann
-
Ryan Schmidt