centos: Another MySQL daemon already running with the same unix socket - mysql

Question

I have a strange error when starting mysqld service:
Another MySQL daemon already running with the same unix socket.
I've tried to list running services and stopping them but the same error happens when starting mysqld service.
I can try to remove the mysqld and reinstall it but will this remove the database too?

Answer 1

To prevent the problem from occurring, you must perform a graceful shutdown of the server from the command line rather than powering off the server.
# shutdown -h now
This will stop the running services before powering down the machine.
Based on Centos, an additional method for getting it back up again when you run into this problem is to move mysql.sock:
# mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak
# service mysqld start
Restarting the service creates a new entry called mqsql.sock

Answer 2

TL;DR:
Run this as root and you'll be all set:
rm $(grep socket /etc/my.cnf | cut -d= -f2) && service mysqld start
Longer version:
You can find the location of MySQL's socket file by manually poking around in /etc/my.conf, or just by using
grep socket /etc/my.cnf | cut -d= -f2
It is likely to be /var/lib/mysql/mysql.sock. Then (as root, of course, or with sudo prepended) remove that file:
rm /var/lib/mysql/mysql.sock
Then start the MySQL daemon:
service mysqld start
Removing mysqld will not address the problem at all. The problem is that CentOS & RedHat do not clean up the sock file after a crash, so you have to do it yourself. Avoiding powering off your system is (of course) also advised, but sometimes you can't avoid it, so this procedure will solve the problem.

Answer 3

I have found a solution for anyone in this problem
change the socket dir to a new location in my.cnf file
socket=/var/lib/mysql/mysql2.sock
and service mysqld start
or the fast way as GeckoSEO answered
# mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak
# service mysqld start

Answer 4

My solution to this was a left over mysql.sock in the /var/lib/mysql/ directory from a hard shutdown.
Mysql thought it was already running when it was not running.

Answer 5

Just open a bug report with your OS vendor asking them to put the socket in /var/run so it automagically gets removed at reboot. It's a bug to keep this socket after an unclean reboot, /var/run is the spot for these kinds of files.

Answer 6

in order to clean automatically .sock file, place these lines in file /etc/init.d/mysqld immediately after "start)" block of code
test -e /var/lib/mysql/mysql.sock
SOCKEXIST=$?
ps cax | grep mysqld_safe
NOPIDMYSQL=$?
echo NOPIDMYSQL $NOPIDMYSQL
echo SOCKEXIST $SOCKEXIST
if [ $NOPIDMYSQL -eq 1 ] && [ $SOCKEXIST -eq 0 ] ; then
echo "NOT CLEAN"
rm -f /var/lib/mysql/mysql.sock
echo "FILE SOCK REMOVED"
else
echo "CLEAN"
fi
it worked for me. I had to do this because I have not an UPS and often we have power supply failures.
regards.

Answer 7

It may sometime arises when MySQL service does not shut down properly during the OS reboot.
The /var/lib/mysql/mysql.sock has been left. This prevents 'mysqld' from starting up.
These steps may help:
1: service mysqld start
killall -9 mysqld_safe mysqld
service mysqld start
2: rm /var/lib/mysql/mysql.sock
service mysqld start

Answer 8

To start the MySQL service, you can remove '/var/lib/mysql/mysql.sock' and start the MySQL service again:
Remove the socket file:
[root#server ~]# rm /var/lib/mysql/mysql.sock
rm: remove socket `/var/lib/mysql/mysql.sock'? yes
Start the MySQL service:
[root#server~]# service mysqld start
Starting mysqld: [ OK ]
It will help you to resolve your problem.

Answer 9

It's just happen because of abnormal termination of mysql service. delete or take backup of /var/lib/mysql/mysql.sock file and restart mysql.
Please let me know if in case any issue..

Answer 10

I just went through this issue and none of the suggestions solved my problem. While I was unable to start MySQL on boot and found the same message in the logs ("Another MySQL daemon already running with the same unix socket"), I was able to start the service once I arrived at the console.
In my configuration file, I found the following line: bind-address=xx.x.x.x. I randomly decided to comment it out, and the error on boot disappeared. Because the bind address provides security, in a way, I decided to explore it further. I was using the machine's IP address, rather than the IPv4 loopback address - 127.0.0.1.
In short, by using 127.0.0.1 as the bind-address, I was able to fix this error. I hope this helps those who have this problem, but are unable to resolve it using the answers detailed above.