Arch Linux

I can confirm this. Current socket path breaks PHP.

Why was this moved to /tmp/mysql/ in the first place? The correct location for socket- and pid files is /var/run/, maybe even /var/run/mysql/, but not /tmp/mysql.

@Jan
yes this make no sense, sock file will be into /var/run/mysqld/ with mysql-5.1.40-2

Indeed, after upgrading my Drupal instance became completely unusable until I created a link from /tmp/mysql.sock to /tmp/mysqld/mysql.sock. Would be nice if PHP was updated to reflect the future change to /var/run.

yes, I lost the whole day trying to fix this. I am building mysql 5.1.41-2 that should fix everything.

Thanks - will check it out as soon as its available.

PHP should probably be rebuilt against mysql 5.1.41-2 because the pdo_mysql extension takes the socket path from `mysql_config --socket' which in versions <5.1.41-2 still points at /tmp/mysql.sock (and --with-mysql-sock=/var/run/mysqld/mysqld.sock, of course).

I already tried that and php still doesn't work

I rebuild my php52 aur package with '--with-mysql-sock=/var/run/mysqld/mysqld.sock' for a server I'm managing and it worked fine.

I'll try with PHP 5.3 since you mention that it has problems.

Confirmed. It appears that mysqlnd (the native driver PHP 5.3 has for mysql) looks specifically for /tmp/mysql.sock (see ext/mysqlnd/mysqlnd.c, around line 539).

PHP 5.3.1 doesn't seem to do anything differently regarding the above, so it may need to be patched.

Actually, scratch that. The mysqlnd_connect function uses '/tmp/mysql.sock' only if another socket path hasn't been specified when it's called.

Right, looks like I have to patch mysqlnd. Calling mysql without specifying the socket worked before. So requiring this now would be a nasty regression.

Looking at ext/mysql/config.m4, it seems to me that the socket path we specify is not taken into account when we build with mysqlnd.

I'm testing a patch right now to verify this assumption.

Yes, I think this is correct. The sock configure parameter is not used within mysqlnd.

I think it's supposed to be used by the mysql/mysqli/pdo_mysql extensions which call mysqlnd_connect with a socket parameter. However, PHP_MYSQL_UNIX_SOCK_ADDR doesn't seem to get defined when mysqlnd is enabled.

I'm attaching the patch I'm trying to test, but I'm having trouble recreating the configure script (autoreconf freaks out O.o).

Nice try. ;) I think this one should be reported upstream.

I tried to build it with mysqlnd.c patched. Of course I can connect now, but utf8 does not work anymore. This is unrelated to this bug but will delay the release of a new php package. For now I'd recommend to downgrade the mysql packages. Those should never have been moved to extra in their current state.

Reported upstream: http://bugs.php.net/bug.php?id=50231. In the mean time, Pierre's patch solves this issue. :)

Pierre, how do you mean utf8 doesn't work? I upgraded a server to mysql-5.1.41-2 today, along with php52-5.2.11-3 from the AUR [1]. A Drupal site that's hosted on this server still functions correctly. Maybe it's a problem with PHP 5.3.1 or mysqlnd? .-.

----
[1] http://aur.archlinux.org/packages.php?ID=30384

I am on it. For now it seems that utf8 is working in general. I just have problems with an old database. But that one might just be broken.

If the default collation is UTF8, you have to call "SET NAMES latin1" or whatever is your charset/collation to work with non-UTF8 input. Without that option, anything that is non-UTF8 will get corrupted or even chopped.

If I dump my db using "--default-character-set=latin1 -c --insert-ignore --skip-set-charset" and then import into the new DB utf8 works as expected. I am still not sure what went wrong here. Maybe I missed some character conversion during the 4.0->4.1 upgrade. But that's going a little off-topic.

@Evangelos Foutras (foutrelis): Thanks for filing an upstream report.

So, php-*-5.3.1-1-x86_64 uses the new socket now.

Nice work Pierre. It connects fine now, without any socket path specification in /etc/php/php.ini.

yeah!! good job Pierre!

The pdo_mysql extension still looks for /tmp/mysql.sock. Was php-5.3.1-1 built against mysql-5.1.41-2 or -1?

Sorry, I should have checked earlier, before saying that it works fine.

[foutrelis@failboat ~]$ strings /usr/lib/php/modules/pdo_mysql.so | grep sock
pdo_mysql.default_socket
/tmp/mysql.sock
unix_socket

Also see my previous comment: http://bugs.archlinux.org/task/17179#comment53409

Looks like pdo is sufferd by the smae bug as mentioned above. PDO_MYSQL_UNIX_ADDR is not set during configure. Until this is fixed upstream I'll simply patch the hardcoded path here as well.

Yes, you're right; it's the same situation. >.<

I'll include this information in the bug report upstream.

OK, pdo should be fixed in -2.

I think there is still an issue. When pdo_mysql.default_socket is empty (the default), it will fail with:

[foutrelis@foutboxd ~]$ php -r 'new PDO("mysql:", "root");'
PHP Warning: PDO::__construct(): [2002] Invalid argument (trying to connect via unix://) in Command line code on line 1
PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] Invalid argument' in Command line code:1
Stack trace:
#0 Command line code(1): PDO->__construct('mysql:', 'root')
#1 {main}
thrown in Command line code on line 1

But when it's commented out, or set to /var/run/mysqld/mysqld.sock, it will work as expected:

[foutrelis@foutboxd ~]$ php -r 'new PDO("mysql:", "root");'
PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: NO)' in Command line code:1
Stack trace:
#0 Command line code(1): PDO->__construct('mysql:', 'root')
#1 {main}
thrown in Command line code on line 1

Hums. .-.

Took me a while, but I tracked this bug down!

The attached patch makes pdo_mysql use the pdo_mysql.default_socket in php.ini only if it's nonempty.

Can be applied with:

# don't use empty pdo_mysql.default_socket from php.ini
patch -p1 -i ${srcdir}/pdo-mysql-default-socket-nonempty.patch || return 1

I'll file a bug report upstream to get this fixed in future versions.

Upstream bug report: http://bugs.php.net/bug.php?id=50240.

Patch regarding pdo_mysql.default_socket has been merged upstream. The bug itself is not critical so I guess it can wait until PHP 5.3.2 is released. :)

I have added the patch to -3. Well, even though PDO isn't used by that many projects it's a regression that breaks code that had worked before.

Thanks Pierre.