I'm getting this error when trying to log into MySQL from the command line:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

I think this means that MySQL hasn't been started yet. So I try to start it:

sudo /etc/init.d/mysql start

and I get this message:

* Starting MySQL database server mysqld [fail] 

Where do I look/what do I do to get MySQL to start? I am running Ubuntu 8.04 and installed MySQL through apt-get. I have been able to get it started and used it a couple times so I don't know why it just stopped working.

Update: When running sudo /etc/init.d/mysql status I get the message:

* MySQL is stopped.

Update #2: My log files (/var/log/mysql.log & /var/log/mysql.err) are empty (if these are the right ones)

  • what happens when you sudo /etc/init.d/mysql status
    – emgee
    Oct 17, 2009 at 22:27

10 Answers 10


On Ubuntu 12.04 I had this same problem after changing buffer sizes in /etc/mysql/my.cnf file, I think I got a little carried away. Anyway after trying to change them back to the default setting MySQL still would not start.

I tried several different methods to get it resolved, I did notice that /var/run/mysql/mysql.sock was missing. This could be an issue so you may check there and if its missing you can replace it by doing the following:

sudo touch /var/run/mysql/mysql.sock
sudo chown mysql /var/run/mysql/mysql.sock

This did NOT fix the problem for me! But it may for some.

What I had to do was completely reinstall MySQL, to do this you will need to use the sudo command. The steps to completely removing and reinstalling MySQL are as follows:

Remove MySQL

sudo apt-get --purge remove mysql-server
sudo apt-get --purge remove mysql-client
sudo apt-get --purge remove mysql-common

Optionally you may use aptitude, by replacing apt-get --purge with aptitude

Clean UP

sudo apt-get autoremove
sudo apt-get autoclean

Remove MySQL dir

sudo rm -rf /etc/mysql

Install MySQL

sudo apt-get install mysql-server mysql-client

MySQL should now be running, you can check this by doing the following:

sudo service mysql status

You should see

mysql start/running, process xxxxx

Hope this helps, and thought I might add after doing this all my databases and tables where still available, however I did have to recreate the users and passwords for those databases.

Note: If you had mysql extension for php, you will need to reinstall this too.

sudo apt-get install php5-mysql
  • This worked for me but I had to change it to: sudo touch /var/run/mysqld/mysqld.sock and I found this out from the end of the /var/log/syslog (e.g. change to mysqld) Mar 15, 2014 at 18:26
  • Is it /var/run/mysqld or /var/run/mysql? May 7, 2015 at 1:22
  • touching the sock file is a bad idea- you've created a regular file, when its really a socket, which is a special kind of file.
    – Criggie
    Nov 3, 2019 at 5:33

WARNING: This is dangerous, your mysql will NOT be safe and anyone will be able to connect, edit, etc your tables, do not leave your server running with this command.

Try starting it in safe mode: /usr/local/mysql/bin/safe_mysqld --user=mysql --skip-grant-tables

If this works then there might be problems with your information_schema or your mysql table(s). If it doesn't work than something is wrong with your install.

  • 1
    This is good, it gives you detailed errors in syslog. The command has changed, on Ubuntu 12.04 it is sudo /usr/bin/mysqld_safe --user=mysql --skip-grant-tables
    – newz2000
    Oct 5, 2012 at 2:16

Check your log files as in the other answers. Also, check that you have enough (or any disk-space). MySQL can behave in this way on an empty partition.

df -h

If it's not that, check out MySQL's docs on debugging a server. Their myisamchk (if you're using MyISAM) is particularly useful.


I also recently got this problem after updating ubuntu. Not yet sure what exactly the problem is. One worakround that worked for the moment to get mysql running though was to do:

sudo aa-complain /etc/apparmor.d/*mysql*

That makes it work, indicating that apparmor stopped mysql from running, and explaining why the logs are empty probably too: mysql was not allowed to run.

It remains an odd issue, as so far there are no "complaints" from this in /var/log/apparmor, and the only audit entry in kern.log are from chaning the profile to complain mode.

Note that in doing this I also added an (empty) /etc/apparmor.d/local/usr.sbin.mysql file as the aa-complain commanded complained about not finding this file.

  • Thank you very much! After getting close to ripping my hair out, that finally fixed it.
    – Olathe
    Apr 14, 2013 at 16:00

I had the same problem with my 512MB Digital Ocean droplet.

Turned out it is due to insufficient memory.

An immediate solution is to restart other services to free up memory eg.

sudo service apache2 restart

Then hopefully, with enough memory, you should be able to restart mysql

sudo service mysql restart

The long term solution is to either get more RAM, or create swap memory.


Take a look at your log files. On Debian at least, you get mysql* logs in /var/log.

  • 3
    mysql.err and mysql.log are both empty
    – Andrew
    Oct 17, 2009 at 23:36

Had this same problem, turns out the solution was staring me in the face. The drive was full. You get no logs because there is no where to write them.....


The same problem plagued me for ages on an Ubuntu 12.04 Digital Ocean VPS with mysql 5.6 installed from a PPA. The symptoms were the that the mysql.sock file at /var/run/mysqld/mysql.sock would get removed but never recreated, so I was having to manually run the following commands every time mysql was updated or the server rebooted:

sudo touch /var/run/mysqld/mysql.sock
sudo chown mysql /var/run/mysqld/mysql.sock

This was from Kyle C's answer (except with mysqld instead of mysql). In the end I downgraded to mysql 5.5 which comes when you would normally perform a sudo apt-get install mysql-server command. However it wasn't straight forward so here is what I had to do:

# Manually get mysql running if it is not
sudo touch /var/run/mysqld/mysql.sock
sudo chown mysql /var/run/mysqld/mysql.sock
sudo service mysql start

# take a dump of all databases 
# we are going to remove the mysql files so don't skip this)
mysqldump -u root -p > all-databases.sql

# Completely remove mysql
sudo apt-get remove --purge mysql-server mysql-client mysql-common
sudo apt-get autoremove
sudo apt-get autoclean

# Remove mysql 5.6 from debs (otherwise it will reinstall 5.6)
rm /etc/apt/sources.list.d/ondrej-(mysql something please check)

# remove a flag that would prevent the installation
# because it is seen as a downgrade
sudo rm /var/lib/mysql/debian-5.6.flag

# I had to remove the mysql files as well
# reference http://ubuntuforums.org/showthread.php?t=1998260&page=3
rm -rf /var/lib/mysql
rm -rf /etc/mysql*

# Install mysql
sudo apt-get install mysql-server mysql-client mysql-common php5-mysql

# manually update the all-databases.sql file and 
# remove all STATS_PERSISTENT clauses on table creation statments

# re import the databses
mysql -u root -p < all-databases.sql

# restart apache
sudo service apache2 restart

# at this point my wordpress site stated error connecting to database.
# This was resolved by logging into mysql and running:

Hopefully this will help someone else having the same pain.


figure this might help others... so here it is.

I wanted to migrate my mysql 5.5 (ubuntu's default) to the new 5.7
(wanted to play arround with the new native JSON type)

I followed the instructions to install the latest version....
but MySQL did not want to start.

Spent quite some time looking and then found this line in the /var/log/mysql/errors.log:

unknown variable 'key_buffer=16M'

and that's something that is set in /etc/mysql/my.cnf that, during the upgrade, I chose to keep.

So, quite easy after that:
replaced my my.cnf with my.cnf.dpkg-dist version located in the same directory...

Then had to run

sudo mysql_upgrade -u root -p sudo service mysql restart

and now MySQL is back up and running


Found another variation on what can be wrong. I moved the data directory, and turns out I forgot to chown the directory for the mysql user, which also fails with no output whatsoever. Obviously wrong in hindsight, but a lack of error-message makes every trivial problem hard to find.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.