MySQL server socket problem

[John Reid]

Having briefly run MySQL successfully from a C program, the next time I
booted up mysqld failed

Relevant syslog info was:

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!

(mysqld.sock does not exist)

Checked this out on the Web and found

This bug can be fixed by:
1) Adding a line that says
include "/etc/bind/rndc.key";
to /etc/bind/named.conf
and then
2) Making /etc/bind/rndc.key be owner root:bind mode 640
chown root:bind /etc/bind/rndc.key

I did this but it did not fix the problem.

Any ideas?




_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Nick Rout]

Post by John Reid
Having briefly run MySQL successfully from a C program, the next time I
booted up mysqld failed
       error: 'Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)'
'/var/run/mysqld/mysqld.sock' exists!
(mysqld.sock does not exist)
Checked this out on the Web and found
       1) Adding a line that says
               include "/etc/bind/rndc.key";
               to /etc/bind/named.conf
       and then
       2) Making /etc/bind/rndc.key be owner root:bind mode 640
               chown root:bind /etc/bind/rndc.key
I did this but it did not fix the problem.
Any ideas?

Is mysqld running?

ps ax|grep mysqld

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Robin Sheat]

Post by John Reid
Having briefly run MySQL successfully from a C program, the next time I
booted up mysqld failed
error: 'Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)'
'/var/run/mysqld/mysqld.sock' exists!
(mysqld.sock does not exist)

This is saying that something is trying to connect to mysqld and
failing. Which is correct if starting mysqld failed. I think the
relevant syslog info might be before this.

I don't know what distro you're on, so I'm going to assume Debian or
Debian-like.

What happens when you run 'sudo /etc/init.d/mysql restart'?

Post by John Reid
Checked this out on the Web and found
1) Adding a line that says
include "/etc/bind/rndc.key";
to /etc/bind/named.conf
and then
2) Making /etc/bind/rndc.key be owner root:bind mode 640
chown root:bind /etc/bind/rndc.key

I'm 99% sure that's not going to do anything for you. In particular, it
seems to be talking about the bind nameserver, which you probably aren't
even running.

Robin.

[John Reid]

Steve

cat /etc/mysql/my.conf | grep socket

gives

# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
socket = /var/run/mysqld/mysqld.sock
socket = /var/run/mysqld/mysqld.sock
socket = /var/run/mysqld/mysqld.sock

This same line also appears twice in /etc/mysql/debian.cnf

Nick

mysqld is not running


Robin

Good point. I did a restart and got the following in syslog


Dec 14 16:46:39 debian mysqld_safe: Starting mysqld daemon with databases
from /var/lib/mysql
Dec 14 16:46:39 debian mysqld: 111214 16:46:39 [Note] Plugin 'FEDERATED'
is disabled.
Dec 14 16:46:39 debian mysqld: 111214 16:46:39 InnoDB: Started; log
sequence number 0 44233
Dec 14 16:46:39 debian mysqld: 111214 16:46:39 [ERROR] /usr/sbin/mysqld:
unknown variable 'lc-messages-dir=/usr/share/mysql'
Dec 14 16:46:39 debian mysqld: 111214 16:46:39 [ERROR] Aborting
Dec 14 16:46:39 debian mysqld:
Dec 14 16:46:39 debian mysqld: 111214 16:46:39 InnoDB: Starting shutdown...
Dec 14 16:46:45 debian mysqld: 111214 16:46:45 InnoDB: Shutdown
completed; log sequence number 0 44233
Dec 14 16:46:45 debian mysqld: 111214 16:46:45 [Note] /usr/sbin/mysqld:
Shutdown complete
Dec 14 16:46:45 debian mysqld:
Dec 14 16:46:45 debian mysqld_safe: mysqld from pid file
/var/run/mysqld/mysqld.pid ended
Dec 14 16:46:54 debian /etc/init.d/mysql[3008]: 0 processes alive and
'/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted
in
Dec 14 16:46:54 debian /etc/init.d/mysql[3008]: #007/usr/bin/mysqladmin:
connect to server at 'localhost' failed
Dec 14 16:46:54 debian /etc/init.d/mysql[3008]: error: 'Can't connect to
local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Dec 14 16:46:54 debian /etc/init.d/mysql[3008]: Check that mysqld is
running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Dec 14 16:46:54 debian /etc/init.d/mysql[3008]:


This suggests that 'unknown variable 'lc-messages-dir=/usr/share/mysql' is
the source of the problem.

But what can I do about it?

Post by Robin Sheat

Post by John Reid
Having briefly run MySQL successfully from a C program, the next time I
booted up mysqld failed
error: 'Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)'
'/var/run/mysqld/mysqld.sock' exists!
(mysqld.sock does not exist)

This is saying that something is trying to connect to mysqld and
failing. Which is correct if starting mysqld failed. I think the
relevant syslog info might be before this.
I don't know what distro you're on, so I'm going to assume Debian or
Debian-like.
What happens when you run 'sudo /etc/init.d/mysql restart'?

Post by John Reid
Checked this out on the Web and found
1) Adding a line that says
include "/etc/bind/rndc.key";
to /etc/bind/named.conf
and then
2) Making /etc/bind/rndc.key be owner root:bind mode 640
chown root:bind /etc/bind/rndc.key

I'm 99% sure that's not going to do anything for you. In particular, it
seems to be talking about the bind nameserver, which you probably aren't
even running.
Robin.
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Robin Sheat]

Post by John Reid
This suggests that 'unknown variable
'lc-messages-dir=/usr/share/mysql' is
the source of the problem.
But what can I do about it?

That looks very much like the cause of your problem.

Option the first:

What version of MySQL are you running (and what debian version?)
lc-messages-dir was added in 5.5, I wonder if you're running an older
version somehow, but perhaps with a newer config. Hmm, do you maybe have
mysql-server-5.1 installed, rather than mysql-server (which, in Debian
6, will be 5.5 or thereabouts.)

Perhaps try: sudo aptitude install mysql-server. It should give you the
option of removing mysql-server-5.1. That should be safe, but I'd take a
backup first if you have data you care about, just to be sure.

Option the second:

Find it and nuke it from orb^W^W^W^W comment it out :)

Try:

sudo grep -r 'lc-messages-dir' /etc/mysql and see if anything comes up.

If it does, edit the file that's in and put a '#' at the start of that
line.

If it doesn't, it might be coming from somewhere else:
sudo grep -r 'lc-messages-dir' /etc/
will hopefully give you something useful.

If you find it and comment it out, try sudo /etc/init.d/mysql restart
again and hopefully it'll work.


Robin.

[John Reid]

Problem solved!

Once again, thank you NZLUGgers.

As suggested by Robin Sheat I installed mysql-server-5.5. using aptitude
which allowed me to uninstall mysql-server-5.1.

Last week I had a problem with missing mysql.h (in fact an empty
/usr/include/mysql). This was overcome by following Steve Holdaway's
suggestion of installing libmysqlclient-dev using apt-get.

However, I did not upgrade mysql-server as well and so client and server
finished up out-of-step which incurred the present problem.

How do you know whether to use dpkg, apt-get or aptitude? It looks like
aptitude is the most high level, so why not use it all the time?

Which one should I use when doing routine Debian upgrades?

Cheers

John

Post by Robin Sheat

Post by John Reid
This suggests that 'unknown variable
'lc-messages-dir=/usr/share/mysql' is
the source of the problem.
But what can I do about it?

That looks very much like the cause of your problem.
What version of MySQL are you running (and what debian version?)
lc-messages-dir was added in 5.5, I wonder if you're running an older
version somehow, but perhaps with a newer config. Hmm, do you maybe have
mysql-server-5.1 installed, rather than mysql-server (which, in Debian
6, will be 5.5 or thereabouts.)
Perhaps try: sudo aptitude install mysql-server. It should give you the
option of removing mysql-server-5.1. That should be safe, but I'd take a
backup first if you have data you care about, just to be sure.
Find it and nuke it from orb^W^W^W^W comment it out :)
sudo grep -r 'lc-messages-dir' /etc/mysql and see if anything comes up.
If it does, edit the file that's in and put a '#' at the start of that
line.
sudo grep -r 'lc-messages-dir' /etc/
will hopefully give you something useful.
If you find it and comment it out, try sudo /etc/init.d/mysql restart
again and hopefully it'll work.
Robin.
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Jim Cheetham]

Post by John Reid
How do you know whether to use dpkg, apt-get or aptitude? It looks like
aptitude is the most high level, so why not use it all the time?

Everything on a stable Debian system should come from "the
repositories", and therefore you should always use apt-get or
aptitude, which are equivalent in this regard.

Using dpkg directly in order to install files is a mechanism of last
resort, and in general you should never be doing this unless you know
100% why you are needing to do it.

-jim

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Nick Rout]

Post by Jim Cheetham

Post by John Reid
How do you know whether to use dpkg, apt-get or aptitude? It looks like
aptitude is the most high level, so why not use it all the time?

Everything on a stable Debian system should come from "the
repositories", and therefore you should always use apt-get or
aptitude, which are equivalent in this regard.

IIRC aptitude keeps a record of what it installed and why, so if you
install a package with a huge number of dependencies, then want to
uninstall it, aptitude will remove all the dependencies (other than
those that are also dependencies of other packages that will remain on
the system).

This is good for inveterate fiddlers like me who often install stuff
to try it out, then want to get rid of it and all dependencies.

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Jim Cheetham]

Post by Nick Rout
IIRC aptitude keeps a record of what it installed and why, so if you
install a package with a huge number of dependencies, then want to
uninstall it, aptitude will remove all the dependencies (other than
those that are also dependencies of other packages that will remain on
the system).

That certainly was a key difference when aptitude originally came out,
but my understanding is that apt-get now has the equivalent feature
(not sure if they can share data or not though).

I still prefer aptitude as a single interface for search, install and
info, rather than using different apt- commands for those operations.
It's not a big deal though.

-jim

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Robin Sheat]

Post by John Reid
How do you know whether to use dpkg, apt-get or aptitude? It looks like
aptitude is the most high level, so why not use it all the time?

That's basically right. apt-get and aptitude are quite similar, apt-get
is older and has a wider range of features. So, sometimes there's
something you need that aptitude simply can't do. However, in the core
stuff, I find that aptitude tends to be better. In particular it's
smarter about removing things that you no longer need.

So my rule of thumb is to use aptitude unless I need apt-get.

dpkg is a different beast. It's for adding and removing a .deb file. It
doesn't download it for you, or find the required dependencies, or
anything like that. apt-get/aptitude use dpkg in the background.

Robin.

[Nevyn]

Post by John Reid
How do you know whether to use dpkg, apt-get or aptitude? It looks like
aptitude is the most high level, so why not use it all the time?
Which one should I use when doing routine Debian upgrades?
Cheers
John

You could use aptitude all the time although it does tend to pull in more
packages than you need. i.e. it also installs all of the recommended
packages.

apt-get lets you know that perhaps you MIGHT want to install x, y and z
package as well but doesn't install them for you - it just suggests so you
tend to end up with a slightly leaner system.

dpkg is to apt what rpm is to yum. I.e. it's behind the installation of
stuff but doesn't do anything with conflict or dependency resolution or
actually getting the packages.

So personally, I'd use apt-get.

Regards,
Nevyn
http://nevsramblings.blogspot.com/
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Robin Sheat]

Post by Nevyn
You could use aptitude all the time although it does tend to pull in more
packages than you need. i.e. it also installs all of the recommended
packages.

That's because they're recommended.

Debian has three levels of dependencies:
* Depends: this is required.
* Recommends: some things may not work right or fully if this isn't
installed, but nothing's going to break.
* Suggests: you get some extra benefit from this.

On a desktop, I go with the recommends. On a server, I don't or it
usually tries to install X at some point. To change this:
sudo vim /etc/apt/apt.conf.d/90install-recommends
and add the line:
APT::Install-Recommends "0";

Then I can use aptitude with no commands to install things if I want the
option to pick and choose at their dependencies.

Robin.

[Nick Rout]

Post by John Reid
Nick
mysqld is not running

so the question is "why not". Changing all the config files in heaven
and earth is not going to change a service that isn't actually
running.

Try starting the service from the command line. Usually something like

sudo /etc/init.d/mysql start [distro dependent]

also look in your log files [ditto]

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Steve Holdoway]

Post by John Reid
Having briefly run MySQL successfully from a C program, the next time I
booted up mysqld failed
error: 'Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)'
'/var/run/mysqld/mysqld.sock' exists!
(mysqld.sock does not exist)
Checked this out on the Web and found
1) Adding a line that says
include "/etc/bind/rndc.key";
to /etc/bind/named.conf
and then
2) Making /etc/bind/rndc.key be owner root:bind mode 640
chown root:bind /etc/bind/rndc.key
I did this but it did not fix the problem.
Any ideas?

Not sure where you got that answer from, but reconfiguring DNS isn't
going to help!

You have 2 means of addressing this: changing the server, or changing
the client. Usually the former is easier.

Both of these require that you modify my.cnf, and (optionally) restart
the server. Thi file either resides in /etc or /etc/mysql for the major
distros.

To change the server to use /var/run/mysqld/mysqld.sock, add the line

socket = /var/run/mysqld/mysqld.sock


to the block starting
[mysqld]

and restart with /etc/init.d/mysql restart
(this might be /etc/init.d/mysqld)

To change the client to use the current socket, first find out what it
is:

ps -fumysql | grep -v PID | awk '{print $2}' | xargs lsof -p | grep unix

is an one liner that print it out...


You then add

that entry as before in the [client] block using the same format as
before. Unfortunately there are a few languages ( perl IIRC ) that don't
honour this, so I recommend changing the server setup.

hth,

Steve