Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have an amazon ec2 instance running on the Amazon Linux AMI and its a micro instance. I wanted to install Django onto my server so I entered these commands
wget http://www.mlsite.net/blog/wp-content/uploads/2008/11/go
wget http://www.mlsite.net/blog/wp-content/uploads/2008/11/django.conf
chmod 744 go
./go
So after I was done, I ran sudo service httpd restart and sudo service mysqld restart
and This is what came up for mysqld:
Stopping mysqld: [ OK ]
MySQL Daemon failed to start.
Starting mysqld: [FAILED]
So I deleted the django files /usr/local/python2.6.8/site-packages/django_registration.egg
and I tried finding the error and I found out that in my
/etc/my.cnf for the socket, it said
[mysqld]
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under different user or group,
# customize your systemd unit file for mysqld according to the
# instructions in http://fedoraproject.org/wiki/Systemd
datadir=/mnt/ebs/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysqld]
default-storage-engine=INNODB
[mysqld]
default-storage-engine=INNODB
[mysqld]
default-storage-engine=INNODB
[mysqld]
default-storage-engine=INNODB
so I went to /var/lock/subsys/ and there was no mysql.sock. I tried creating one using vim but it still didn't work. Then I checked the error log and it said
120712 20:33:11 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120712 20:33:15 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
UPDATE:
I entered these commands:
cd /var/lib/mysql/
touch mysql.sock
chmod +x mysql.sock
chown mysql:mysql -R *
And it still didn't work...
So I am pretty much lost right now. I know it has something to do with mysql.sock
If you might know a reason why this was caused could you please let me know? I have a wordpress site on my server, so i kind of need MySQL to work. Thanks!
Inspecting the go script you downloaded and executed, I found the following lines:
# Change the MySQL data directory
sed -e 's!/var/lib/mysql$!/mnt/ebs/mysql!' -i /etc/my.cnf
This effectively changes your mysql data directory (datadir setting), so you can't access any previously created database (like the wordpress database).
As a wild guess, I would think that the mysqld can't access /mnt/ebs/mysql and therefore doesn't start. Try to change it back to /var/lib/mysql. However, this might interfere with your django. If you get the django configured mysql to run, you can always add a second my.cnf with another name and other tcp port and run two MySQL servers with different configurations.
The socket error message is about the MySQL server not running. Do not try to emulate the socket by putting a file in its way.
The go script also makes some more changes to my.cnf that could be a problem. Have a look at the go file yourself and try to undo the changes made.
If nothing of the above helps, you can try to start the mysqld process from command line by hand, using the same arguments as the service script does, plus an added --verbose and post its output.
Ok, I figured it out thanks to #escitalopram so I will accept his answer! Ok, django changed my MySQL data directory from /var/lib/mysql to /mnt/ebs/mysql in my /etc/my.cnf, so in my /etc/my.cnf, it said
datadir=/mnt/ebs/mysql and I changed it to datadir=/var/lib/mysql. And everything worked fine. I restarted MySQL hoping for the red [FAILED] message but I got an [OK]. Also, my socket was messed up in /etc/my.cnf but I had already fixed that!
Related
I installed mysql 5.6 on Ubuntu Server 16.04 using this method: https://askubuntu.com/questions/762384/install-mysql-5-6-on-ubuntu-16-04
But i'm having trouble getting mysqld to read /etc/mysql/my.cnf
Specifically i'm trying to set it up for an Atlassian Confluence installation where I have to add in these settings:
[mysqld]
character-set-server=utf8
collation-server=utf8_bin
default-storage-engine=INNODB
max_allowed_packet=256M
innodb_log_file_size=2G
I've checked mysqld --help --verbose and it has the my.cnf in its path. Here's the relevant output:
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf The following
groups are read: mysqld server mysqld-5.6
I know that mysql is reading the file because if I change [mysqld] to [mysql] the arguments are correctly printed when I run mysql --print-defaults also if I put a wrong line in the file mysql will fail to start and tell me where the syntax error is. However mysqld does not report any arguments for mysqld --print-defaults or tell me about syntax errors in the file.
What else can I try?
Solved:
my.cnf was a symbolic link. I deleted it and made it an actual file. Now mysqld --show-defaults is working! So apparently mysql will follow the symlink but mysqld will not. Good to know.
my.cnf was a symbolic link. I deleted it and made it an actual file. Now mysqld --show-defaults is working. So apparently mysql will follow the symlink but mysqld will not.
For mysqld as I know only hard links works. Or maybe you just had wrong permission, on original my.cnf file to which you put symbolic link.
Last night, my MySQL server went down unexpectedly. On attempting to restart (with service mysql restart - I'm root) it merely hangs. With the mysql -u root -p command, I get:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2).
I then tried to start the daemon manually (mysqld). The prompt would hang for about 2 seconds, and then return. On closer inspection of the error logs, I got:
2016-01-22T19:18:32.399584Z 0 [ERROR] Could not create unix socket lock file /var/run/mysqld/mysqld.sock.lock.
2016-01-22T19:18:32.399622Z 0 [ERROR] Unable to setup unix socket lock file.
2016-01-22T19:18:32.399646Z 0 [ERROR] Aborting
I then tried chown mysql /var/run/mysqld, chmod -R 775 /var/run/mysqld and apt-get install mysql-community-server --reinstall. No luck.
I have looked around, and couldn't find a solution. Any help here?
Note: I am Running Debian 8 (Jessie) with MySQL community Server 5.7.10
I just ran into this. The mysql install was a little weird and was missing
/var/run/mysqld/
MySQLd was attempting to create the socket and lock file but the parent directory was missing. I simply created the directory
sudo mkdir /var/run/mysqld
chowned it to mysql
sudo chown mysql:mysql /var/run/mysqld
I was then able to start mysqld normally.
I experienced the same issue today on my Ubuntu server. But I think the solution is NOT to disable locking. In my case, a look at the system log (dmesg | tail and journalctl -xe) revealed that it's an apparmor issue and the solution can be found in this question.
I had following error
[ERROR] Unix socket lock file is empty /var/lib/mysql/mysql.sock.lock.
This error came up as a result that my server was lacking space 100% use (see below)
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 41153856 28531384 12187364 100% /
Make sure the folder exists with the proper permissions
chown mysql:mysql /var/lib/mysql/
And make sure to delete the file so the mysql server could generate a new one
rm /var/lib/mysql/mysql.sock.lock
Posting this answer, in case it helps someone with the same config as me. I had similar issue with this configuration:
Host OS: Ubuntu 20.04, MySql server: 8.0
The following error was seen in /var/log/mysql/error.log during run of systemctl start mysql
[ERROR] [MY-010273] [Server] Could not create unix socket lock file /var/run/mysqld/mysqld.sock.lock.
Fix was similar:
mkdir -p /var/run/mysqld/
chmod 777 /var/run/mysqld/
And of course, I had enough space wherever mysql server was being installed.
Below commands worked for me.
sudo mkdir /var/run/mysqld
sudo chmod 777 /var/run/mysqld -R
Also may be out of disk space.
For those running docker. If you're already running mysql in docker, you will also get such an error. Removing the mysql container solved the problem for me.
It's best to look at the log files (/usr/local/var/mysql/*.local.err) before attempting any of the more generic answers.
In my case first it complained of not being able to open the socket file ([Server] Could not open unix socket lock file /tmp/mysql.sock.lock.) and once I changed permissions, it complained of not being able to remove it! ([Server] Could not remove unix socket lock file /tmp/mysql.sock.lock errno 13.)
Removed it and run mysql.server start and DONE.
Rename /var/lib/mysql/mysql.sock.lock & /var/lib/mysql/mysql.sock to /var/lib/mysql/mysql.sock.lock.bck & /var/lib/mysql/mysql.sock.bck respectively and start mysqld. It works
If you are using docker to run MySQL, please check if there is enough allocated disk space in docker preferences.
Fixed. Add skip-external-locking to my.cnf under the [mysqld] section, and then reboot the entire system. This should fix it, for anyone who finds this. Also if you backed up your data, then attempted to restore and were told to rm ib* to make it work, you need the ibdata file.
I need some help to set MAX connections value permanently in MySql. I have tried but I can't find a permanent solution. Now, I am using temporary solution by changing in command prompt like in this article.
Since this question shows up on the search results when people search for a solution, and now that the solution has changed, I felt it necessary to post an answer.
Ubuntu 15.04+ no longer respects the limits set in /etc/security/limits.conf. So if you set max connections and you don't see any effect, have a look at the log file at sudo vim /var/log/mysql/error.log and you'll see Changed limits: max_connections: 214 (requested 5000).
Solution:
Copy the limits for mysql from the systemd config file to /etc/systemd using:
sudo cp /lib/systemd/system/mysql.service /etc/systemd/system/
sudo vim /etc/systemd/system/mysql.service
Then add the following lines to the bottom of the file:
LimitNOFILE=infinity
LimitMEMLOCK=infinity
You could also use a finite number instead of infinity.
Now reload systemd config:
sudo systemctl daemon-reload
Thank you Very much i inserted the code into the MY.ini file and it solved the problem.
in c:/xampp/mysql/bin/my.ini file under the [mysqld] section i inserted the following line
**
max_connections = 250
**
Later restart the xampp server to take effect.
if we give set-variable=max_connections=250 Mysql server is not starting.
Once again thank you very much.
I had the same problem using Ubuntu 16.04.
Had to do it this way:
sudo vim /etc/systemd/system/mysql.service
Added the lines at the bottom of the file:
LimitNOFILE=infinity
LimitMEMLOCK=infinity
Reloaded systemd config:
sudo systemctl daemon-reload
Increased the number of files the system could open:
ulimit -n 4096
Edited my.cnf like this:
vi /etc/mysql/mysql.conf.d/mysqld.cnf
Looked for the max_connections and changed it´s value to 20000.
To make sure the settings become permanent performed a mysql service restart:
sudo service mysql restart
Went to phpmyadmin and checked the max_connections global variable using:
SHOW VARIABLES like '%max_connections';
It worked - Now when the daemon restarts I have the same max_connections that I had before.
you can set that in my.cnf, Mysql Doc
I quote
You can increase this value in main config file (e.g., /etc/my.cnf or /etc/mysql/my.cnf) using this syntax:
[mysqld]
set-variable=max_connections=250
i think you need to restart mysql after changes to take effect.
I am having a bit of an issue that popped up over the past weekend.
One of my servers was rebooted and when the server came it started a default instance of mysql that is configured upon installation. It uses port 3306 as a default and blocks one of my instances from coming up.
How can I remove this default instance from booting and instead boot my instances in /etc/my.cnf ?
I think what is happening is it is going to /var/lib/mysql and starting an instance based off some default configuration as there is not a my.cnf file located here, but I find this code in init.d:
#Set some defaults
mysqld_pid_file_path=
if test -z "$basedir"
then
basedir=/usr
bindir=/usr/bin
if test -z "$datadir"
then
datadir=/var/lib/mysql
fi
But I don't see any my.cnf file at that location that it could be pulling configuration options from.
My data directories change per instance and they are all specified in /etc/my.cnf
I appreciate any effort spent helping with this issue.
Try this:
$ my_print_defaults --defaults-file=/etc/my.cnf mysqld
This will show you what it thinks datadir is set to, according to your config file.
I've seen config files get confused as people edit them, or even automated tools may edit the config file and append new config entries. Keep in mind if the config file has more than one line defining datadir, the last such line in the file takes precedence.
If you have an instance of mysqld starting up automatically at boot time, I'd use chkconfig to find out when that's happening. For example, here's a command run on my VM:
$ chkconfig
...
mysql 0:off 1:off 2:on 3:on 4:on 5:on 6:off
...
The numbers 0 through 6 are runlevels, and "on" means that when the given runlevel starts, the /etc/init.d/mysql service script is run by init.
You can also use chkconfig to modify which runlevels a given service starts under, and even to disable the service at all runlevels, so that it won't start automatically ever.
$ chkconfig --level 2345 mysql off
Refer to man chkconfig for more uses.
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?
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
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.
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
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.
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.
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.
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
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.
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..
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.