I am following mysql on Cygwin.
# To begin MySQL setup run the following:
mysql_install_db
# Run mysql - you'll get a firewall alert from windows if you have it active.
mysqld_safe &
# Immediately following that, it would be wise to run the following:
mysql_secure_installation
During the mysql_install_db, I was asked who the database (DB) would be for. I specified a non-administrator account nonadmin.
For the mysql_secure_installation process, I followed the similarly named MariaDB page. In contrast to the description, I was told that I had no root password, so I set it to the same as my cygwin and windows administrator account.
I lost track of whether which account was used for each of the three commands above, but here is what I remember:
mysql_install_db: Ran as nonadmin, but prompted for admin password
mysqld_safe: Run as nonadmin
mysql_secure_installation: Attempted as nonadmin, abandoned, and
completed as administrator account admin
It seems that I should restart the server after the final step. Using ps -ef, I noted that process mysqld belongs to nonadmin. Using nonadmin, I attempted the mysqladmin shutdown command at mysql on Cygwin. I get:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'nonadmin'#'localhost' (using password: NO)'
I tried the variation of the command that prompts the user for a password: mysqladmin -p shutdown. I did this twice, entering the cygwin/windows passwords for nonadmin and admin. Both times, I get:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'nonadmin'#'localhost' (using password: YES)'
This totalled 3 attempts. I then switched to the admin account and retried all 3 attempts. I got the above messages, but with the username admin:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'admin'#'localhost' (using password: NO)'
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'admin'#'localhost' (using password: YES)'
So no joy connecting to the daemon to shut it down. As an alternative, I want to avoid clobbering mysqld with kill -9 because I like things to terminate cleanly (though I will probably do so soon).
As another alternative, I've come across references to /etc/init.d, but I have no such file.
Can anyone please explain why I can't connect to the daemon to shut it down?
Also, I'm new to MySQL, so if possible, it'd be nice to find a way back to the process at mysql on Cygwin rather than deviating from it too much.
Thanks.
What I ended up doing was kill -9 on all mysql looking processes shown by ps -ef. I then deleted /var/lib/mysql -- and accidentally deleted all of /var/lib/*. Subsequently, therefore, I reinstalled all of my Cygwin packages, thus starting from a clean slate.
I also found the following more detailed process at this alaya page for installing a MySQL/MariaDB database on Cygwin, after which I was able to shut down the MySQL server.
from the Administrator terminal run:
mysql_install_db
Start the mysql server:
mysqld_safe &
then run:
mysql_secure_installation
You should then be able to log in to MariaDB from a non-administrative shell with:
mysql -u root -p
The initial mysql_install_db step generates the following useful looking information, which I'm capturing here because I'm not sure if there is a way to get it again.
Installing MariaDB/MySQL system tables in '/var/lib/mysql' ...
2019-05-01 23:00:06 0 [Warning] InnoDB: innodb_open_files 300 should not be greaterthan the open_files_limit 256
OK
To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system
PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER !
To do so, start the server, then issue the following commands:
'/usr/bin/mysqladmin' -u root password 'new-password'
'/usr/bin/mysqladmin' -u root -h fmaPC password 'new-password'
Alternatively you can run:
'/usr/bin/mysql_secure_installation'
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the MariaDB Knowledgebase at http://mariadb.com/kb or the
MySQL manual for more instructions.
You can start the MariaDB daemon with:
cd '/usr' ; /usr/bin/mysqld_safe --datadir='/var/lib/mysql'
You can test the MariaDB daemon with mysql-test-run.pl
cd '/usr/mysql-test' ; perl mysql-test-run.pl
Please report any problems at http://mariadb.org/jira
The latest information about MariaDB is available at http://mariadb.org/.
You can find additional information about the MySQL part at:
http://dev.mysql.com
Consider joining MariaDB's strong and vibrant community:
https://mariadb.org/get-involved/
During the mysql_secure_installation step, I followed the recommendation to set a root password. Instead of the mysql -u root -p step, then, I could instead issue the following to stop the MySQL server:
mysqladmin -u root -p shutdown
I made an important discovery made about this process from the point of view of a user without administrator rights. Contrary to what is suggested on the alaya page cited above, the above process does not have to be done from an administrator account. Importantly, the user accounts with which one can connect to the MySQL server has nothing to do with the user accounts on the host system (Windows or *nix) (a fact that I got from perusing MariaDB knowledgebase). I suspect that any user on the host system can connect to any user account on the server via the socket that it presents [1], with the right password.
I also found that the above process works on a machine that has very restrictive Windows firewall policies. Even if the server (the mysqld_safe & step) and client (the mysql -u root -p step) are started from the same non-administrative account, the Windows firewall will issue a warning about curtailing some features. I suspect that the trigger is the creation of a socket for connecting to the server. Despite the warning, however, ps -ef shows the server to be running. Therefore, I suspect that the firewall restriction consists of allowing only loop-back connections. The mysql_secure_installation step apparently disallows external connections, and I found that after this step, stopping and relaunching the server no longer triggers the firewall warning. So the effect of mysql_secure_installation seems to persist into subsequent sqld launches, at least when they are started via mysqld_safe.
[1] "Present" might not be the right terminology here, as I'm more of an analyst rather than a developer or administrator.
When I attempted to connect to a local MySQL server during my test suite, it
fails with the error:
OperationalError: (2002, "Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)")
However, I'm able to at all times, connect to MySQL by running the command line
mysql program. A ps aux | grep mysql shows the server is running, and
stat /tmp/mysql.sock confirm that the socket exists. Further, if I open a
debugger in except clause of that exception, I'm able to reliably connect
with the exact same parameters.
This issue reproduces fairly reliably, however it doesn't appear to be 100%,
because every once in a blue moon, my test suite does in fact run without
hitting this error. When I attempted to run with sudo dtruss it did not reproduce.
All the client code is in Python, though I can't figure how that'd be relevant.
Switching to use host 127.0.0.1 produces the error:
DatabaseError: Can't connect to MySQL server on '127.0.0.1' (61)
sudo /usr/local/mysql/support-files/mysql.server start
This worked for me. However, if this doesnt work then make sure that mysqld is running and try connecting.
The relevant section of the MySQL manual is here. I'd start by going through the debugging steps listed there.
Also, remember that localhost and 127.0.0.1 are not the same thing in this context:
If host is set to localhost, then a socket or pipe is used.
If host is set to 127.0.0.1, then the client is forced to use TCP/IP.
So, for example, you can check if your database is listening for TCP connections vi netstat -nlp. It seems likely that it IS listening for TCP connections because you say that mysql -h 127.0.0.1 works just fine. To check if you can connect to your database via sockets, use mysql -h localhost.
If none of this helps, then you probably need to post more details about your MySQL config, exactly how you're instantiating the connection, etc.
For me the problem was I wasn't running MySQL Server.
Run server first and then execute mysql.
$ mysql.server start
$ mysql -h localhost -u root -p
I've seen this happen at my shop when my devs have a stack manager like MAMP installed that comes preconfigured with MySQL installed in a non standard place.
at your terminal run
mysql_config --socket
that will give you your path to the sock file. take that path and use it in your DATABASES HOST paramater.
What you need to do is point your
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'test',
'USER': 'test',
'PASSWORD': 'test',
'HOST': '/Applications/MAMP/tmp/mysql/mysql.sock',
'PORT': '',
},
}
NOTE
also run which mysql_config if you somehow have multiple instances of mysql server installed on the machine you may be connecting to the wrong one.
I just changed the HOST from localhost to 127.0.0.1 and it works fine:
# settings.py of Django project
...
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'db_name',
'USER': 'username',
'PASSWORD': 'password',
'HOST': '127.0.0.1',
'PORT': '',
},
...
For me, the mysql server was not running. So, i started the mysql server through
mysql.server start
then
mysql_secure_installation
to secure the server and now I can visit
the MySQL server through
mysql -u root -p
or
sudo mysql -u root -p
depending on your installation.
When, if you lose your daemon mysql in mac OSx but is present in other path for exemple in private/var do the following command
1)
ln -s /private/var/mysql/mysql.sock /tmp/mysql.sock
2) restart your connexion to mysql with :
mysql -u username -p -h host databasename
works also for mariadb
Run the below cmd in terminal
/usr/local/mysql/bin/mysqld_safe
Then restart the machine to take effect. It works!!
After attempting a few of these solutions and not having any success, this is what worked for me:
Restart system
mysql.server start
Success!
To those who upgraded from 5.7 to 8.0 via homebrew, this error is likely caused by the upgrade not being complete. In my case, mysql.server start got me the following error:
ERROR! The server quit without updating PID file
I then checked the log file via cat /usr/local/var/mysql/YOURS.err | tail -n 50, and found the following:
InnoDB: Upgrade after a crash is not supported.
If you are on the same boat, first install mysql#5.7 via homebrew, stop the server, and then start the 8.0 system again.
brew install mysql#5.7
/usr/local/opt/mysql#5.7/bin/mysql.server start
/usr/local/opt/mysql#5.7/bin/mysql.server stop
Then,
mysql.server start
This would get your MySQL (8.0) working again.
Check number of open files for the mysql process using lsof command.
Increase the open files limit and run again.
This may be one of following problems.
Incorrect mysql lock.
solution: You have to find out the correct mysql socket by,
mysqladmin -p variables | grep socket
and then put it in your db connection code:
pymysql.connect(db='db', user='user', passwd='pwd', unix_socket="/tmp/mysql.sock")
/tmp/mysql.sock is the returned from grep
2.Incorrect mysql port
solution: You have to find out the correct mysql port:
mysqladmin -p variables | grep port
and then in your code:
pymysql.connect(db='db', user='user', passwd='pwd', host='localhost', port=3306)
3306 is the port returned from the grep
I think first option will resolve your problem.
I have two sneaky conjectures on this one
CONJECTURE #1
Look into the possibility of not being able to access the /tmp/mysql.sock file. When I setup MySQL databases, I normally let the socket file site in /var/lib/mysql. If you login to mysql as root#localhost, your OS session needs access to the /tmp folder. Make sure /tmp has the correct access rights in the OS. Also, make sure the sudo user can always read file in /tmp.
CONJECTURE #2
Accessing mysql via 127.0.0.1 can cause some confusion if you are not paying attention. How?
From the command line, if you connect to MySQL with 127.0.0.1, you may need to specify the TCP/IP protocol.
mysql -uroot -p -h127.0.0.1 --protocol=tcp
or try the DNS name
mysql -uroot -p -hDNSNAME
This will bypass logging in as root#localhost, but make sure you have root#'127.0.0.1' defined.
Next time you connect to MySQL, run this:
SELECT USER(),CURRENT_USER();
What does this give you?
USER() reports how you attempted to authenticate in MySQL
CURRENT_USER() reports how you were allowed to authenticate in MySQL
If these functions return with the same values, then you are connecting and authenticating as expected. If the values are different, you may need to create the corresponding user root#127.0.0.1.
I think i saw this same behavior some time ago, but can't remember the details.
In our case, the problem was the moment the testrunner initialises database connections relative to first database interaction required, for instance, by import of a module in settings.py or some __init__.py.
I'll try to digg up some more info, but this might already ring a bell for your case.
Make sure your /etc/hosts has 127.0.0.1 localhost in it and it should work fine
if you get an error like below :
django.db.utils.OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")
Then just find your mysqld.sock file location and add it to "HOST".
Like i am using xampp on linux so my mysqld.sock file is in another location. so it is not working for '/var/run/mysqld/mysqld.sock'
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'asd',
'USER' : 'root',
'PASSWORD' : '',
'HOST' : '/opt/lampp/var/mysql/mysql.sock',
'PORT' : ''
}
}
Had this same problem. Turned out mysqld had stopped running (I'm on Mac OSX). I restarted it and the error went away.
I figured out that mysqld was not running largely because of this link:
http://dev.mysql.com/doc/refman/5.6/en/can-not-connect-to-server.html
Notice the first tip!
I had to kill off all instances of mysql by first finding all the process IDs:
ps aux | grep mysql
And then killing them off:
kill -9 {pid}
Then:
mysql.server start
Worked for me.
Check that your mysql has not reached maximum connections, or is not in some sort of booting loop as happens quite often if the settings are incorrect in my.cnf.
Use ps aux | grep mysql to check if the PID is changing.
Looked around online too long not to contribute. After trying to type in the mysql prompt from the command line, I was continuing to receive this message:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
This was due to the fact that my local mysql server was no longer running. In order to restart the server, I navigated to
shell> cd /user/local/bin
where my mysql.server was located. From here, simply type:
shell> mysql.server start
This will relaunch the local mysql server.
From there you can reset the root password if need be..
mysql> UPDATE mysql.user SET Password=PASSWORD('MyNewPass')
-> WHERE User='root';
mysql> FLUSH PRIVILEGES;
The socket is located in /tmp. On Unix system, due to modes & ownerships on /tmp, this could cause some problem. But, as long as you tell us that you CAN use your mysql connexion normally, I guess it is not a problem on your system. A primal check should be to relocate mysql.sock in a more neutral directory.
The fact that the problem occurs "randomly" (or not every time) let me think that it could be a server problem.
Is your /tmp located on a standard disk, or on an exotic mount (like in the RAM) ?
Is your /tmp empty ?
Does iotopshow you something wrong when you encounter the problem ?
# shell script ,ignore the first
$ $(dirname `which mysql`)\/mysql.server start
May be helpful.
I had faced similar problem recently. Went through many answers. I got it working by following steps.
change the socket path in /etc/my.cnf (as i was repeatedly getting error with /tmp/mysql.sock ) reference to change the socket path
run mysqld_safe to restart the server as it is the recommended way to restart in case of errors. reference to mysqld_safe
If you installed through Homebrew, try to run
brew services start mysql
Configure your DB connection in the 'Manage DB Connections dialog. Select 'Standard (TCP/IP)' as connection method.
See this page for more details
http://dev.mysql.com/doc/workbench/en/wb-manage-db-connections.html
According to this other page a socket file is used even if you specify localhost.
A Unix socket file is used if you do not specify a host name or if you
specify the special host name localhost.
It also shows how to check on your server by running these commands:
If a mysqld process is running, you can check it by trying the
following commands. The port number or Unix socket file name might be
different in your setup. host_ip represents the IP address of the
machine where the server is running.
shell> mysqladmin version
shell> mysqladmin variables
shell> mysqladmin -h `hostname` version variables
shell> mysqladmin -h `hostname` --port=3306 version
shell> mysqladmin -h host_ip version
shell> mysqladmin --protocol=SOCKET --socket=/tmp/mysql.sock version
in ubuntu14.04 you can do this to slove this problem.
zack#zack:~/pycodes/python-scraping/chapter5$ **mysqladmin -p variables|grep socket**
Enter password:
| socket | ***/var/run/mysqld/mysqld.sock*** |
zack#zack:~/pycodes/python-scraping/chapter5$***ln -s /var/run/mysqld/mysqld.sock /tmp/mysql.sock***
zack#zack:~/pycodes/python-scraping/chapter5$ ll /tmp/mysql.sock
lrwxrwxrwx 1 zack zack 27 11月 29 13:08 /tmp/mysql.sock -> /var/run/mysqld/mysqld.sock=
For me, I'm sure mysqld is started, and command line mysql can work properly. But the httpd server show the issue(can't connect to mysql through socket).
I started the service with mysqld_safe&.
finally, I found when I start the mysqld service with service mysqld start, there are issues(selinux permission issue), and when I fix the selinux issue, and start the mysqld with "service mysqld start", the httpd connection issue disappear. But when I start the mysqld with mysqld_safe&, mysqld can be worked. (mysql client can work properly). But there are still issue when connect with httpd.
If it's socket related read this file
/etc/mysql/my.cnf
and see what is the standard socket location. It's a line like:
socket = /var/run/mysqld/mysqld.sock
now create an alias for your shell like:
alias mysql="mysql --socket=/var/run/mysqld/mysqld.sock"
This way you don't need root privileges.
Simply try to run mysqld.
This was what was not working for me on mac.
If it doesn't work try go to /usr/local/var/mysql/<your_name>.err to see detailed error logs.
Using MacOS Mojave 10.14.6 for MySQL 8.0.19 installed via Homebrew
Ran sudo find / -name my.cnf
File found at /usr/local/etc/my.cnf
Worked for a time then eventually the error returned. Uninstalled the Homebrew version of MySQL and installed the .dmg file directly from here
Happily connecting since then.
so I have two free gears on OpenShift.
One is a PHP with MySql 5.7 from:
https://github.com/icflorescu/openshift-cartridge-mysql
To which I can remote login from my PC without any problem by SSH tunnel.
Now on the second gear I wanted to create Spring Boot app that would connect to DB on the first gear. Using env | grep MYSQL on first gear I receive:
OPENSHIFT_MYSQL_DB_PORT=13306
OPENSHIFT_MYSQL_DB_HOST=127.10.104.130
So this + my logging data was put into Spring application.properties, after successfull build Spring crashed at data pool creation because it could not connect to database so I SSHed into second hear and tried accessing MySQL instance from first gear via:
mysql -u root -h 127.10.104.130 -P 13306 but I get error message:
Can not connect to MySQL Server on '127.10.104.130' (113)
After that I tried:
mysql -u root -h myAppName-domain.rhcloud.com -P 13306 which results in longer time of connection but ultimatelly failling with:
Can not connect to MySQL Server on 'myAppName-domain.rhcloud.com' (110)
And I can easly ping gear#1 from gear#2 so I am confused - do I need some extra sql config or firewall settings? I am also doing tail on mysql logs and nothing is showing up like connection is not even made.
If you are connecting on another gear you have to use the OPENSHIFT_MYSQL_DB_PROXY_PORT instead.
The easiest way I find to tell if its a database issue or a network issue is to simply try to telnet to the remote mysql host.
Ex - this should result in a connection timeout if you are on a different gear.
telnet 127.10.104.130 13306
But this should connect:
telnet <mysql app id>.domain.rhcloud.com <WHATEVER THE PROXY PORT IS>
I'm the author of the openshift-cartridge-mysql mentioned above.
It's been a while since I've published that cartridge, but if I remember correctly, the setup script is quite unassuming and there's nothing created by default, so you have to create your own users, databases and explicitly grant the appropriate privileges.
Connect from your PC either by ssh or by Workbench over ssh tunnel, create your user and database, then execute something like:
GRANT ... ; FLUSH PRIVILEGES;
You can learn more on MySQL's GRANT command in the official manual.
There's a line in the repo README exemplifying how you could grant remote access to root, which is not as unsafe as it looks because you can only access the DB gear from your main application gear.
But ideally you'd want to limit the access as much as possible (to a specific user coming from a specific host/IP, such as your main application gear). Something like this:
GRANT ALL ON appdb.* TO 'appuser'#'appgear';
Don't forget to FLUSH PRIVILEGES when you're done.
I hope this helps,
#icflorescu