ID: 45468
Updated by: j...@php.net
-Summary: socket file problem when mysqlnd is enabled
Reported By: michael dot kofler at gmx dot com
-Status: No Feedback
+Status: Assigned
-Bug Type: MySQLi related
+Bug Type: MySQL related
-Operating System: *
+Operating System: * (not win32)
-PHP Version: 5.3.0alpha1
+PHP Version: 5.3CVS, 6CVS (2009-04-25)
-Assigned To: mysql
+Assigned To: johannes
New Comment:
This is clearly a bug:
# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'
Output with --with-mysql=mysqlnd:
Warning: mysql_connect(): [2002] No such file or directory (trying to
connect via unix:///tmp/mysql.sock) in Command line code on line 1
# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'
No output (error) --with-mysql (without mysqlnd) -> connection works.
The problem is with code in ext/mysqlnd/mysqlnd.c:537-543 which forces
using the socket in this case.
Note: Same happens with mysqli. This bug also makes all mysql(i) tests
fail unless one uses some environment variables while running them.
Previous Comments:
------------------------------------------------------------------------
[2009-02-03 11:59:28] and...@php.net
Hi,
it was a problem, the Unix path, in the extensions, not mysqlnd. Yes,
mysqlnd uses /tmp/mysql.sock, but actually there are no configure
options for mysqlnd. --with-mysql-sock is actually an option of
ext/mysql . It wasn't used in the past, as far as I recall, but current
5_3 and HEAD do use it to set default value for the socket path, which
can be overwritten by the user. Both for ext/mysql and mysqli.
This if from ext/mysql/php_mysql.c :
#ifdef MYSQL_UNIX_ADDR
STD_PHP_INI_ENTRY("mysql.default_socket",
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysql_globals, mysql_globals)
#else
STD_PHP_INI_ENTRY("mysql.default_socket", NULL,
PHP_INI_ALL, OnUpdateStringUnempty, default_socket,
zend_mysql_globals, mysql_globals)
#endif
This is from ext/mysqli/mysql.c :
#ifdef PHP_MYSQL_UNIX_SOCK_ADDR
STD_PHP_INI_ENTRY("mysqli.default_socket",
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysqli_globals, mysqli_globals)
#else
STD_PHP_INI_ENTRY("mysqli.default_socket", NULL,
PHP_INI_ALL, OnUpdateStringUnempty, default_socket,
zend_mysqli_globals, mysqli_globals)
#endif
MYSQL_UNIX_ADDR is a macro, for PHP_MYSQL_UNIX_ADDR, which is defined
by the configure script if --with-mysql-sock is used.
In this regard, PDO doesn't use --with-mysql-sock. PDO_MYSQL used
mysql_config to find the socket, but for mysqln defaults to
/tmp/mysql.sock , which seems like bug, because of inconsistency.
This is something for Johannes
Best,
Andrey
------------------------------------------------------------------------
[2009-02-03 11:43:38] johan...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
--with-mysql-sock should work now properly
------------------------------------------------------------------------
[2008-08-07 08:01:44] michael dot kofler at gmx dot com
re-tested on Linux with alpha1, compiled with this configuration:
configure --with-mysqli=mysqlnd \
--with-mysql=mysqlnd \
--with-mysql-sock=/var/run/mysqld/mysqld.sock \
--enable-pdo \
--with-pdo-mysql=mysqlnd \
--with-apxs2=/usr/bin/apxs2 \
--with-zlib \
--with-gd \
--with-config-file-scan-dir=/etc/php5/apache2 \
--with-jpeg-dir=/usr/lib \
--enable-exif \
--libdir=/usr/lib \
--enable-mbstring
also tried
--with-mysql-sock=/var/run/mysqld \
result: mysql, mysqli and PDO/mysql, all using mysqlnd, still look for
the socket file /tmp/mysql.sock and ignore --with-mysql-sock
if I compile without mysqlnd and without the --with-mysql-sock option,
PHP automatically finds the right socket file, probably because libmysql
reads the [client] settings in /etc/mysql/my.cnf
my solution for now: I changed all socket options in /etc/mysql/my.cnf
and /etc/mysql/debian.cnf
it would be better either to provide a working configure option for PHP
(--mysqlnd-sock=...) or to evaluate my.cnf within mysqlnd
------
PS: as to mysqlnd not supporting old MySQL authentication: perfectly
fine for me, but *do document* it in some PHP 5.3 update advisory;
otherwise I am pretty sure the update to PHP 5.3 will cause trouble for
many MySQL users
------------------------------------------------------------------------
[2008-07-23 11:37:26] u...@php.net
>From the begin on mysqlnd has been described as MySQL 4.1+. We won't
make it work with any MySQL <4.1. See also the MySQL Lifecycle Policy.
Those distributions that use old_passwords=1 have two choices: use a
different configure for PHP and use libmysql like ever since or take the
challenge of an upgrade. PHP 4 will become history at some point in time
and so will MySQL 4.1.
If you are using MySQL < 4.1 and it works with libmysql all is fine.
mysqlnd is does not support MySQL <4.1 nor does it support
old_passwords=1: no bug.
------------------------------------------------------------------------
[2008-07-21 18:23:31] and...@php.net
The old authentication method is insecure and should not be used. Also
MySQL servers before 4.1 are already antique. If you have an application
that uses them you might don't want to change you PHP, and you still
have the possibility to compile PHP with libmysql. mysqlnd will never
support the old authentication. This saves hassles when checking what is
possible and what not. 4.0 and earlier are too old.
I just committed a fix, so it will be possible to configure PHP with
--with-mysql-sock to use another socket. However, the problem _wasn't_
in mysqlnd but in the extensions that sit on it. If you use libmysql it
will look by default for a socket under /tmp/mysql.sock . That's the
default. During server compilation you can set different default value
which will appear then in mysql_version.h that comes with libmysql and
what is used by the binary. mysqlnd uses /tmp/mysql.sock and there is no
way to change it on it's level, but with the existing option it will be
on the extension level.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45468
--
Edit this bug report at http://bugs.php.net/?id=45468&edit=1
