A MySQL client on Unix can connect to the
mysqld server in two different ways: By
using a Unix socket file to connect through a file in the
filesystem (default /tmp/mysql.sock), or
by using TCP/IP, which connects through a port number. A Unix
socket file connection is faster than TCP/IP, but can be used
only when connecting to a server on the same computer. A Unix
socket file is used if you don't specify a hostname or if you
specify the special hostname localhost.
If the MySQL server is running on Windows 9x or Me, you can
connect only via TCP/IP. If the server is running on Windows
NT, 2000, XP, or 2003 and is started with the
--enable-named-pipe option, you can also
connect with named pipes if you run the client on the host
where the server is running. The name of the named pipe is
MySQL by default. If you don't give a
hostname when connecting to mysqld, a MySQL
client first tries to connect to the named pipe. If that
doesn't work, it connects to the TCP/IP port. You can force
the use of named pipes on Windows by using
. as the hostname.
The error (2002) Can't connect to ...
normally means that there is no MySQL server running on the
system or that you are using an incorrect Unix socket filename
or TCP/IP port number when trying to connect to the server.
The error (2003) Can't connect to MySQL server on
'
indicates that the network connection has been refused. You
should check that there is a MySQL server running, that it has
network connections enabled, the network port you specified is
the one configured on the server, and that the TCP/IP port you
are using has not been blocked by a firewall or port blocking
service.
server' (10061)
Start by checking whether there is a process named mysqld running on your server host. (Use ps xa | grep mysqld on Unix or the Task Manager on Windows.) If there is no such process, you should start the server. See Section 2.10.2.3, “Starting and Troubleshooting the MySQL Server”.
If a mysqld process is running, you can
check it by trying the following commands. The port number or
Unix socket filename might be different in your setup.
host_ip represents the IP number of the
machine where the server is running.
shell>mysqladmin versionshell>mysqladmin variablesshell>mysqladmin -h `hostname` version variablesshell>mysqladmin -h `hostname` --port=3306 versionshell>mysqladmin -h host_ip versionshell>mysqladmin --protocol=socket --socket=/tmp/mysql.sock version
Note the use of backticks rather than forward quotes with the
hostname command; these cause the output of
hostname (that is, the current hostname) to
be substituted into the mysqladmin command.
If you have no hostname command or are
running on Windows, you can manually type the hostname of your
machine (without backticks) following the
-h option. You can also try -h
127.0.0.1 to connect with TCP/IP to the local host.
Here are some reasons the Can't connect to local
MySQL server error might occur:
mysqld is not running. Check your operating system's process list to ensure the mysqld process is present.
You're running a MySQL server on Windows with many TCP/IP
connections to it. If you're experiencing that quite often
your clients get that error, you can find a workaround
here:
Section B.1.2.2.1, “Connection to MySQL Server Failing on Windows”.
You are running on a system that uses MIT-pthreads. If you are running on a system that doesn't have native threads, mysqld uses the MIT-pthreads package. See Section 2.1.1, “Operating Systems Supported by MySQL Community Server”. However, not all MIT-pthreads versions support Unix socket files. On a system without socket file support, you must always specify the hostname explicitly when connecting to the server. Try using this command to check the connection to the server:
shell> mysqladmin -h `hostname` version
Someone has removed the Unix socket file that
mysqld uses
(/tmp/mysql.sock by default). For
example, you might have a cron job that
removes old files from the /tmp
directory. You can always run mysqladmin
version to check whether the Unix socket file
that mysqladmin is trying to use really
exists. The fix in this case is to change the
cron job to not remove
mysql.sock or to place the socket
file somewhere else. See
Section B.1.4.5, “How to Protect or Change the MySQL Unix Socket File”.
You have started the mysqld server with
the --socket=/path/to/socket option, but
forgotten to tell client programs the new name of the
socket file. If you change the socket pathname for the
server, you must also notify the MySQL clients. You can do
this by providing the same --socket
option when you run client programs. You also need to
ensure that clients have permission to access the
mysql.sock file. To find out where
the socket file is, you can do:
shell> netstat -ln | grep mysql
See Section B.1.4.5, “How to Protect or Change the MySQL Unix Socket File”.
You are using Linux and one server thread has died (dumped
core). In this case, you must kill the other
mysqld threads (for example, with
kill or with the
mysql_zap script) before you can
restart the MySQL server. See Section B.1.4.2, “What to Do If MySQL Keeps Crashing”.
The server or client program might not have the proper
access privileges for the directory that holds the Unix
socket file or the socket file itself. In this case, you
must either change the access privileges for the directory
or socket file so that the server and clients can access
them, or restart mysqld with a
--socket option that specifies a socket
filename in a directory where the server can create it and
where client programs can access it.
If you get the error message Can't connect to MySQL
server on some_host, you can try the following
things to find out what the problem is:
Check whether the server is running on that host by
executing telnet some_host 3306 and
pressing the Enter key a couple of times. (3306 is the
default MySQL port number. Change the value if your server
is listening to a different port.) If there is a MySQL
server running and listening to the port, you should get a
response that includes the server's version number. If you
get an error such as telnet: Unable to connect to
remote host: Connection refused, then there is
no server running on the given port.
If the server is running on the local host, try using
mysqladmin -h localhost variables to
connect using the Unix socket file. Verify the TCP/IP port
number that the server is configured to listen to (it is
the value of the port variable.)
Make sure that your mysqld server was
not started with the --skip-networking
option. If it was, you cannot connect to it using TCP/IP.
Check to make sure that there is no firewall blocking access to MySQL. Your firewall may be configured on the basis of the application being executed, or the post number used by MySQL for communication (3306 by default).
Under Linux or Unix, check your IP tables (or similar) configuration to ensure that the port has not been blocked.
Under Windows, applications such as ZoneAlarm and the Windows XP personal firewall may need to be configured to allow external access to a MySQL server.
If you are running under Linux and Security-Enhanced Linux
(SELinux) is enabled, make sure you have disabled SELinux
protection for the mysqld process.
When you're running a MySQL server on Windows with many
TCP/IP connections to it, and you're experiencing that quite
often your clients get a Can't connect to MySQL
server error, the reason might be that Windows
doesn't allow for enough ephemeral (short-lived) ports to
serve those connections.
By default, Windows allows 5000 ephemeral (short-lived) TCP
ports to the user. After any port is closed it will remain
in a TIME_WAIT status for 120 seconds.
This status allows the connection to be reused at a much
lower cost than reinitializing a brand new connection.
However, the port will not be available again until this
time expires.
With a small stack of available TCP ports (5000) and a high
number of TCP ports being open and closed over a short
period of time along with the TIME_WAIT
status you have a good chance for running out of ports.
There are two ways to address this problem:
Reduce the number of TCP ports consumed quickly by investigating connection pooling or persistent connections where possible
Tune some settings in the Windows registry (see below)
IMPORTANT: The following procedure involves modifying the Windows registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, view the following article in the Microsoft Knowledge Base: http://support.microsoft.com/kb/256986/EN-US/.
Start Registry Editor
(Regedt32.exe).
Locate the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
On the Edit menu, click Add
Value, and then add the following registry
value:
Value Name: MaxUserPort Data Type: REG_DWORD Value: 65534
This sets the number of ephemeral ports available to any user. The valid range is between 5000 and 65534 (decimal). The default value is 0x1388 (5000 decimal).
On the Edit menu, click Add
Value, and then add the following registry
value:
Value Name: TcpTimedWaitDelay Data Type: REG_DWORD Value: 30
This sets the number of seconds to hold a TCP port
connection in TIME_WAIT state before
closing. The valid range is between 0 (zero) and 300
(decimal). The default value is 0x78 (120 decimal).
Quit Registry Editor.
Reboot the machine.
Note: Undoing the above should be as simple as deleting the registry entries you've created.

User Comments
I ran into a commonly reported problem where Connector/J fails to connect to localhost. Many people seem to resolve this problem by referring to 127.0.0.1 instead.
I solved it a different way. My /etc/hosts file contained this:
127.0.0.1 localhost
# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback
When I removed the reference to "localhost" under "::1" the connection succeeded.
I believe this may be a bug in Connector/J or mysqld actually, where something may fail to correctly handle IPv6 addresses. If you try running "mysql -h ::1", that also fails for me (yes, I am running IPv6. SUSE 9.2 seems to turn it on by default).
In any event, here is a possible fix that avoids editing all of the connection references.
[note from Mark Matthews - Dev Lead for Connector/J]
This is fixed in the latest released versions of Connector/J -- It tries all listed addresses for a given hostname.
I was getting this error because the daemon couldn't create a pid file in the requested place. It never told me that it couldn't, it just never wrote it.
Once I made the pid file's location writable by the mysql user, everything started working.
I'm on Gentoo Linux, with emerged dev-db/mysql-4.0.22.
I couldnt connect to the server from a remote host (with proper privileges and IP/host or % as host) not even with telnet, after all the checks (mysqld running and doublecheck permissions) and some fighting i found the solution (may sound lame), in the mysql configuration file (/etc/mysql/my.conf) comment the line (69):
#bind-address = 127.0.0.1
restart mysql (/etc/init.d/mysql restart)
and everything works like a charm:)
Good Luck.
im using yahoo as my server host and well the faq said to use "mysql" in place of "localhost".
that fixed my problem.
Bryan
I'm using Debian 3.1 (Sarge) and by default if you installed mysql with apt-get, the skip-networking variable is turned on. Which means you won't be able to connect remotely to the server. All you need to do to be able to connect remotely is go to /etc/mysql/mysql.cnf and comment out the skip-networking variable and you'll be able to connect remotely. Hopefully this is useful.
With mysql 4.1 skip-networking defaults to off, however bind to localhost is enabled by default as eduardo above pointed out. So depending on what version of mysql is being run, both eduardo and joshua are correct.
I ran "grant all on MY_DATABASE.* to 'USER' identified by 'PASSWORD' "
but when I was trying to run perl script which supposed to connect to MY_DATABASE on the same PC(Debian with MySQL4.1 -> apt-get install) was getting Error -> "DBI connect('MY_DATABASE:test.com','USER',...) failed: Can't connect to MySQL server on 'test.com' (111) at test.pl line 107 "
I did the same as Eduardo(see above) and it solved my problem. Thanks.
-Yuriy
Read Eduardo A. Romero's post above if you are a Gentoo User! This solved my issues as well!
The "bind-address" line in the my.cnf file (on Debian)
determines whether the MySQL server listens for TCP/IP from the local host only, or from anywhere.
If the line isn't commented out, e.g. if it looks like
bind-address 127.0.0.1
then it will only hear requests from the local host. If you try to connect from other hosts, even on the same LAN, the connection will be refused.
There are two pointers to identify if this is happening:
1. if you
telnet 127.0.0.1 3306
on the host running the server, you'll get a MySQL banner,
but if from another host you try
telnet sqlhost 3306
(where 'sqlhost is the box running the MySQL server) you'll
get
telnet: Unable to connect to remote host: Connection refused
2. On the host running the server, do
netstat -l -t -p
to show what progs are listening on which ports. If you see
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 29945/mysqld
it means the server is only listening locally.
The solution is to comment out the "bind-address" line and restart the server, as noted above.
I have another one: the /etc/hosts file had the wrong IP address for my server (I changed the ip address of the machine and forgot to update the /etc/hosts file). When I fixed the /etc/hosts file, it still didn't work. But when I deleted the user and re-added the user with the correct /etc/host file, it finally worked.
Using /usr/sbin/mysqld --verbose allowed me to see that there was an unrecognized variable 'old_passwords=1', which I later found out was being set by Debian in /etc/mysql/my.cnf for some backward compatibility with *Debian* software. Removing this entry from the configuration file was all that was needed to get my server working again. This bug has been addressed by the Debian package maintainers: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321578
I had the same problem that I could not connect from a lapton on the network. All of the information above was very helpful.
The last step I had to take to connect from my laptop running XP to mysql on a linux machine running Suse was stop the firewall on the linux machine via Yast.
I had a default install of mysql on a 'Mandriva 2005' distribution.
By default, the file /etc/sysconfig/mysqld contains the following line:
MYSQLD_OPTIONS="--skip-networking"
I had to remove this.
All of the above solutions do not work for Fedora Core 4
I updated from ver 3.23 to 4.1 and ran into the same problem. All of the above didn't solve the problem. Although mysqld started without any error, I checked the logfile: /var/log/mysqld.log on my system. There seemed to be a problem with a missing default language set.
Next I commented out the default-language in my.cnf (there was no default-lang specified in my.cnf 3.23) and restarted mysqld, which solved my problem.
""I had a default install of mysql on a 'Mandriva 2005' distribution.By default, the file /etc/sysconfig/mysqld contains the following line:MYSQLD_OPTIONS="--skip-networking"
I had to remove this.""
Mandriva 2006 is the same way. This post worked for me.
This worked for me on SuSe 10.
Disabling IPv6 for MySQLd wil fix the socket creation problem for now.
Actually just changing the filename from /etc/sysconfig/mysqld to /etc/sysconfig/zzmysqld solved the issue for me. Mandriva 10.2 (2005)
I'm using Slackware 10.2 and i had the same problem. I solved it this way, i uncommented SKIP="--skip-networking" string in /etc/rc.d/rc.mysqld file. After that change and restarting the server (/etc/rc.d/rc.mysqld restart) the problem disappeared.
So a typical call to access a MySQL database might look like this:
mysql_connect(localhost, $username, $password);
I have hosting through godaddy.com, and this is what I ended up using for in place of "localhost" to connect with a MySQL database using the 'mysql_connect' function. This may vary depending on which type of account you have through godaddy, but this worked for me so it might be worth trying.
1.) Log in to the hosting manager.
2.) Click on 'Databases', and then 'MySQL'.
3.) Next to the database you'd like to access, click on the icon that has a little computer with a spreadsheet behind it (note that your mouse pointer won't turn into a little hand; it'll just be the regular arrow).
4.) Some sample code will be displayed. Find the line in that code that looks like the line shown below (where the variable $hostname is set equal to something):
$hostname="mysql105.secureserver.net";
Your code will probably differ only in the number that is after 'mysqul' and before '.secureserver.net' (so instead of "105" you might have something like "49").
Note that the line of code that actually accesses the database is:
mysql_connect($hostname,$username, $password) OR DIE ("Unable to connect to database! Please try again later.");
where the variable $hostname (which you identify earlier) is being used to connect to the database.
Good luck!
Chris
I faced a similar problem where mysql 5.0.19 (upgraded from 4.1.13) would just not connect from neither perl/java nor php. Command line connections were OK for root but not for other users even they had same privileges as the root user. Problem resolved by correcting the hosts file. Apparently if localhost isnt the first alias for 127.0.0.1, then you're in for trouble. Same situation with a postgres 8.1 installation. Good luck.
I came to this error in a different perspective. I used C/C++ programming language with mysql.h + libmysqlclient library to communicate with the mySQL server.
"Can't connect to local MySQL server(111)", I got that error because I declare MYSQL object, try to use the object in mysql_real_connect function without calling to mysql_init function earlier.
Reference: http://dev.mysql.com/doc/refman/4.1/en/mysql-real-connect.html
===============================================================
MYSQL mysql;
mysql_init(&mysql);
mysql_options(&mysql,MYSQL_READ_DEFAULT_GROUP,"your_prog_name");
if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
{
fprintf(stderr, "Failed to connect to database: Error: %s\n",
mysql_error(&mysql));
}
===============================================================
Remember,
Once you have edited the my.conf under /etc/mysql and removed the bind-host line you must also do the following:
mysql> grant all prvileges on *.* to <userName>@<hostName> identified by 'passwrd'
where the user will own the database acces and the host is the machine you're connecting from.
Thanks to Spyros for this post, which u can find:
http://forums.mysql.com/read.php?34,34957,56380#msg-56380
Posted by Joshua Jackson on February 2 2005 10:19am [Delete] [Edit]
I'm using Debian 3.1 (Sarge) and by default if you installed mysql with apt-get, the skip-networking variable is turned on. Which means you won't be able to connect remotely to the server. All you need to do to be able to connect remotely is go to /etc/mysql/mysql.cnf and comment out the skip-networking variable and you'll be able to connect remotely. Hopefully this is useful.
THIS WAS WERY USEFUL.
IN MANDRIVA 2006 FREE EDITION,
I HAVE TO CHANGE
/etc/sysconfig/mysqld
AND COMMENT OUT (#) skip-networking
AFTER THAT, EVERITHING WORKS FINE.
THANKS TO EVERY ONE
regards from Belgrade.
Running Debian 3.1r2
# /etc/init.d/mysql start
Starting MySQL database server: mysqld...failed.
Please take a look at the syslog.
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
but the my.cnf file says
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
so I'm not sure how to use the above suggestions to comment out skip-networking
removing (actually renaming) the my.cnf file fixed this for me.
# mv /etc/mysql/my.cnf /etc/mysql/my-old.cnf
although it does cause a warning on startup, it does actually startup.
/etc/host.allow or /etc/host.deny
I was not successful with all the above tips (but anyhow THANK YOU). After searching around on my server
I found that I had an entry in /etc/host.allow like this:
mysqld : 192.168.0.15 : allow
mysqld : ALL : deny
All other host except the 192.168.0.15 were disabled on the server!!!
After changing the IP-Address to LOCAL everything works fine.
(Don't forget to restart the portmapper after changing this file)
Thank you Christopher Monnier for your write-up. It solved my problem of trying to figure our what host was to be on my new hosting service. This solution worked for me on RackNine and for you on GoDFaddy and should for anyone else connecting thru securenet.
Starting MySQL database server: mysqld...failed.
Please take a look at the syslog.
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
i have solved this problem by checking my hostname and set it back to localhost
1. edit etc/hostname
2.
#> hostname localhost
I have a case to solve this problem.If compile apache --with-mpm=worker,then mysql_connect() also show this message:
Can't connect to MySQL server on "remote_mysqld"
#cd httpd-2.0.55
#./configure --prefix=/usr/local/apache --enable-so --enable-rewrite --enable-deflate --with-mpm=worker
So if you want connect remote mysql server,pls not use --with-mpm=worker
notice:I use php-4.4.1 and mysql4.0.26
Problem connecting to remote MySQL database with Fedora:
Can't connect to MySQL server.
Event though from the http server, I could successfully connect using:
# mysql -u username -p -h server_ip
or
# php -f connect.php
It just wouldn't work through Apache (Ex: //webserver/connect.php)
The solution was to turn on:
SELinux /
--> SELinux Service Protection /
---->Disable SELinux protection for mysqld daemon.
Eduardo Romero's tip worked for Gentoo for me
with 5.0.26. Would be nice to know why, of course.
Also this may be helpful. Try checking your iptables configuration. First I would stop your iptables services by typing.
/etc/init.c/iptables stop
If when you try to get your MySQL Admin to connect to your host server and it connects then you know that you will need to update them within your system. For a UNIX system this would be in ipf configurations. But you can at least stop them and then restart them until your configuration file is updated.
in adition to post of miguel perez on October 1 2005 7:34pm
just put in advanced option in firewall configuration an exception of tcp port '3306'
best regards
When you see the error code 2003 (Not able to connect to remote host) while connecting to a MySQL server installed on a WindowsXP machine from a remote machine, make sure the mysql port and program are set in the windows XP firewall exceptions tab. To do this, go to COntrol Panel --> Windows Firewall --> Exceptions (Tab) --> Add Program. Add the path to mysql-nt.exe and mysql.exe which will be generally in your c:/ProgramFiles/mysql/bin/ directory.
Also add the port 3306 by clicking the Add Port button in the same window. Give the name as mysql and select the type of network as TCP.
Go here:
http://forums.asp.net/thread/1528921.aspx
hope it may help!
I also had a problem similar to Du zoid's, where I could connect from one machine (web server) to another (DB server) using the command-line "php -f file.php", but not from Apache "server.com/file.php".
SELinux was disabled on the DB server, enabled on the Web server, but with the mysqld protection disabled (obviously irrelevant on the Web server), and it still didn't work.
I had to disable SELinux on the Web server to get it to work (?!).
There may be a more selective setting to disable on SELinux on the web server than deactivating it entirely, but it serves my purpose. Only took me 3 days to figure out! :)
Thanks Du zoid!
I posted back on 16/01/05 with a way to solve a connection issue i was having. Now I kind of know the explanation and, as with most things, its quite simple.
bind-address = 127.0.0.1 will make mysqld listen on localhost, and as you might expect you can *only* reach localhost from you own computer.
In order to make mysql listen on ALL your IP's change it to
bind-address = 0.0.0.0
Which is the same as just commenting the line (0.0.0.0 is the default).
So that's the explanation.
0.0.0.0 == listen on all IP addresses. Thus you can connect from the outside world (and localhost).
This is also valid for all other daemons and programs.
Solution for mysql Couldn't find the mysql server or manager
http://javasolution.blogspot.com/2007/04/mysql-couldnt-find-mysql-server-or.html
Add your own comment.