Bug 890535 - Default socket wrong for /usr/libexec/mysqld-wait-ready
Summary: Default socket wrong for /usr/libexec/mysqld-wait-ready
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: 17
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-27 15:19 UTC by John Whitley
Modified: 2013-01-23 01:30 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-12 15:17:11 UTC
Type: Bug


Attachments (Terms of Use)
mysql /etc/my.cnf (4.96 KB, application/octet-stream)
2012-12-27 15:19 UTC, John Whitley
no flags Details

Description John Whitley 2012-12-27 15:19:57 UTC
Created attachment 669635 [details]
mysql /etc/my.cnf

Description of problem:

If 'socket' is not specified in /etc/my.cnf, /usr/libexec/mysqld-wait-ready looks for 'datadir'/mysql.sock, not /var/lib/mysql/mysql.sock


Version-Release number of selected component (if applicable):

mysql-server-5.5.28-2.fc17.x86_64

How reproducible:

very

Steps to Reproduce:
1. Install mysql
2. Use /etc/my.cnf with no socket and non-defaul datadir
3. Try to load with systemctl start mysqld.service
  
Actual results:

mysql loads but /usr/libexec/mysqld-wait-ready hangs until timeout


Expected results:

mysql loads

Additional info:

I have been using mysql 5.5.28 downloaded from oracle on pre-systemd fedora. To use an existing database on F17, I installed mysql using yum, copied /etc/my.cnf and the datadir (/home3/mysql/data) from the working installation.

Initially mysql would not load because the socket nominated in /etc/my.cnf (/tmp/mysql.sock) was not being created and so /usr/libexec/mysqld-wait-ready did not complete.

(Running mysqld-safe by hand did create the socket)

I then commented out the socket line from /etc/my.cnf to use the default. This time the socket /var/lib/mysql/mysql.sock was created but /usr/libexec/mysqld-wait-ready was looking for /home3/mysql/data/mysql.sock
 i.e. ++ /usr/bin/mysqladmin --no-defaults --socket=/home3/mysql/data/mysql.sock --user=UNKNOWN_MYSQL_USER ping 

I then set the socket in /etc/my.cnf to /var/lib/mysql/mysql.sock and then mysql was able to be loaded by  systemd and seems OK now

I have added /etc/my.cnf

Comment 1 Honza Horak 2013-01-02 09:16:24 UTC
Thanks for reporting.

(In reply to comment #0)
> Initially mysql would not load because the socket nominated in /etc/my.cnf
> (/tmp/mysql.sock) was not being created and so
> /usr/libexec/mysqld-wait-ready did not complete.
> 
> (Running mysqld-safe by hand did create the socket)

Just to correct this -- socket probably was created, but since mysql's unit file specifies PrivateTmp, the socket was created in its own namespace. Namespace is always unique for every process, so as a consequence socket was not visible for other processes, not even for mysqld-wait-ready.

> I then commented out the socket line from /etc/my.cnf to use the default.
> This time the socket /var/lib/mysql/mysql.sock was created but
> /usr/libexec/mysqld-wait-ready was looking for /home3/mysql/data/mysql.sock
>  i.e. ++ /usr/bin/mysqladmin --no-defaults
> --socket=/home3/mysql/data/mysql.sock --user=UNKNOWN_MYSQL_USER ping 

mysqld_safe uses the following command to get the socket path:

  ${mysql_unix_port:-${MYSQL_UNIX_PORT:-/var/lib/mysql/mysql.sock}}

so we should indeed change the following in the mysql-wait-ready:

  -get_mysql_option mysqld socket "$datadir/mysql.sock"
  +get_mysql_option mysqld socket "/var/lib/mysql/mysql.sock"

Comment 2 Tom Lane 2013-01-02 19:47:28 UTC
Yeah, you'd have to turn off PrivateTmp if you want to keep the socket in /tmp.

I think that the indirect dependency on $datadir that's now in mysqld-wait-ready was actually correct when it was written, but that was a very long time ago.  I agree it's bogus now given the current coding in mysqld_safe.  Will fix, thanks for the report.

Comment 3 Fedora Update System 2013-01-02 22:56:13 UTC
mysql-5.5.29-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mysql-5.5.29-1.fc17

Comment 4 Fedora Update System 2013-01-02 22:56:24 UTC
mysql-5.5.29-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mysql-5.5.29-1.fc18

Comment 5 Fedora Update System 2013-01-02 22:56:35 UTC
mysql-5.5.29-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mysql-5.5.29-1.fc16

Comment 6 Fedora Update System 2013-01-03 23:50:11 UTC
Package mysql-5.5.29-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mysql-5.5.29-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-0142/mysql-5.5.29-1.fc18
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2013-01-12 15:17:14 UTC
mysql-5.5.29-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2013-01-15 02:34:33 UTC
mysql-5.5.29-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2013-01-23 01:30:06 UTC
mysql-5.5.29-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.