Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.11.0

Bug #2960 mysqli->connect fails due to unspecified socket/port
Submitted: 2004-12-13 18:24 UTC
From: oliver at realtsp dot com Assigned: danielc
Status: Closed Package: DB
PHP Version: 5.0.2 OS: FreeBSD
Roadmaps: (Not assigned)    
Subscription  


 [2004-12-13 18:24 UTC] oliver at realtsp dot com
Description: ------------ DB package V1.68. The mysqli db->connect fails. I googled around and searched the bug db, but couldn't find any mention of this problem. I was amazed since this seems like quite a generic problem for php5.0.2 with mysqli extension? (I was previously running this code on php4.3.x with mysql extension and same version of DB without problems, but on RH Linux). Have I missed something obvious? Seems to be related to Bug #1526, who is also using FreeBSD. Reproduce code: --------------- require_once('DB.php'); $dsn = 'mysqli://username:password@localhost/dbname'; $db = DB::connect($dsn); I also tried with the array connect method, same result. I tracked down the problem to these lines in mysqli.php: } else { $conn = @mysqli_connect( $dsninfo['hostspec'], $dsninfo['username'], $dsninfo['password'], $dsninfo['database'], $dsninfo['port'], $dsninfo['socket'] ); } I inserted my own mysqli_connect call directly above the one in this one, with the same parameters, and it works. The difference is that I don't specify port and socket parameters which are optional according to here: http://uk.php.net/manual/en/function.mysqli-connect.php If I change the mysqli.php above lines as follows: } else { $conn = @mysqli_connect( $dsninfo['hostspec'], $dsninfo['username'], $dsninfo['password'], $dsninfo['database'] // , // $dsninfo['port'], // $dsninfo['socket'] ); } (ie commenting out the optional params) it works fine. Proposed (proper) solution: Should there be some logic to put "benign" values (rather than 'false' currently i think) into these params to stop mysqli_connect() getting confused? Or should we not pass them at all if they are not specified in dsn or connect array? Expected result: ---------------- a valid DB object Actual result: -------------- DB Error: connect failed

Comments

 [2004-12-13 23:35 UTC] danielc
Before the mysqli_connect call, please put in var_dump($dsninfo) and post the results here. Then, what happens if you convert the commented out lines to "null." mysqli.php line 201: $conn = @mysqli_connect( $dsninfo['hostspec'], $dsninfo['username'], $dsninfo['password'], $dsninfo['database'], null, null ); Thanks.
 [2004-12-14 08:13 UTC] oliver at realtsp dot com
thanks for coming back so quickly. sorry, yes I did the vardump when i was tracking down the bug and should have posted that output here in the first place, so here it is (db credentials changed for security reasons of course): array(9) { ["phptype"]=> string(6) "mysqli" ["dbsyntax"]=> string(6) "mysqli" ["username"]=> string(13) "username" ["password"]=> string(8) "password" ["protocol"]=> string(3) "tcp" ["hostspec"]=> string(9) "localhost" ["port"]=> bool(false) ["socket"]=> bool(false) ["database"]=> string(17) "dbname" } so the values for port and socket are both bool(false). Hardcoding them as null in the mysqli_connect() call results in the same error. Additional info: The verbose version of the error is: nativecode=Can't connect to local MySQL server through socket '' (2) looks like the mysqli_connect() call interprets both bool(false) and null as an empty string rather than ignoring these parameters and fails as a result. (I commented those lines out again after null didn't work just to prove that not passing the extra params definitely works, and it does).
 [2004-12-14 08:25 UTC] oliver at realtsp dot com
I also tried just commenting the socket param and leaving the port line in tact. This works! so the problem is specific to the socket param only. The guy in Bug #1526 also spoke about using '/tmp/mysql.sock' as the socket param. This is indeed the correct path to the default location of the mysql unix socket under FreeBSD. Putting this in the mysqli_connect() call, makes it work. However, this is not really a solution, because the mysqli extension should figure out to use the local socket if connecting to localhost, or at least that is my interpretation of this from the php manual: http://uk.php.net/manual/en/function.mysqli-connect.php <quote> Passing the NULL value or the string "localhost" to this parameter, the local host is assumed. When possible, pipes will be used instead of the TCP/IP protocol. </quote>
 [2004-12-14 08:31 UTC] oliver at realtsp dot com
so I have put in a slightly tidier "fix" than just the commenting of the socket param. Not sure if this qualifies as a patch? It works for me, but not sure about other implications. } else { if ($dsninfo['socket']) { $conn = @mysqli_connect( $dsninfo['hostspec'], $dsninfo['username'], $dsninfo['password'], $dsninfo['database'], $dsninfo['port'], $dsninfo['socket'] ); } else { $conn = @mysqli_connect( $dsninfo['hostspec'], $dsninfo['username'], $dsninfo['password'], $dsninfo['database'], $dsninfo['port'] ); } } over to you ;-)
 [2004-12-14 17:10 UTC] danielc
This seems more like a PHP issue than a PEAR DB issue. Can you please try PHP 5.0.3 RC2 and see what happens? Have you looked through PHP's bug database for relevant stuff? Thanks.
 [2004-12-14 17:43 UTC] oliver at realtsp dot com
I have searched the php bugs db for entries relating to mysqli_connect but found nothing. I am not sure I agree that this is a php problem. Basically mysqli.php is calling the mysqli_connect() php function with all optional parameters but failing to provide valid values for some of them (ie the port and socket params). If I say to the php guys, here I want to be able to call mysqli_connect() with socket=false and expect it to just ignore the parameter eventhough I have passed it, then they will just tell me to not do that, right?
 [2004-12-14 18:00 UTC] danielc
They may, they may not. Make the point that most PHP functions gladly accept false/null for optional string arguments without causing problems. Before that, please try the latest release candidate mentioned in my prior comment, just to make sure it hasn't been fixed yet.
 [2004-12-14 18:54 UTC] oliver at realtsp dot com
I am not in a position to compile 5.0.3RC2. But I have posted this bug: http://bugs.php.net/bug.php?id=31094 If this produces no result, I will test again with 5.0.3 when it is released.
 [2004-12-19 08:13 UTC] oliver at realtsp dot com
you were right. just installed php-5.0.3 and the problem has been fixed. closing this bug
 [2005-01-21 03:54 UTC] cere dot yahoo at gmail dot com
This appears to still be a problem in php4-3.10. I am having this exact same problem...though I cannot find a situation that fixes it yet. -Cere