I am getting this error when trying to do a fresh install of d7 alpha-3 but not alpha-1 or any previous dev releases as I have been able to install those. It is also present in the latest dev release. Attached is the phpinfo() output from my server. I am sorry that I can not provide more detail at the moment as my knowledge about PDO is limited, tell e what I should do and I will happily provide more info.
| Comment | File | Size | Author |
|---|---|---|---|
| phpinfo().pdf | 181.86 KB | NiklasBr |
Comments
Comment #1
NiklasBr commentedThe error is still there in todays dev release.
Comment #2
webkenny commentedI am able to install both Alpha3 and the latest dev with no problems, Niklas. On Mac OSX. I will let others chime in here, but I don't believe this should be critical. From the looks of that error message it appears something may be configured improperly on your setup.
Comment #3
yoroy commentedFrom the attached pdf:
PHP Version 5.3.0
mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27 $
Comment #4
Crell commentedHm. I don't believe mysqlnd supports PDO yet. Are you sure you have both PDO and the PDO-MySQL driver?
Comment #5
NiklasBr commented@webkenny,
I have been trying to find out more on this. I have never considered any config errors because I have had a production site running Drupal 6.2-6.16 (and some minor home-brewed stuff) flawlessly on the same machine as well as installed some 7.x-dev releases in late 2009 without any database-related issues. MySQL had been installed via the OS X disk image downloaded from the mysql homepage.
Well, what I found that might be interesting is:
MySQL Admin reports "socket = /tmp/mysql.sock" while php.ini says "pdo_mysql.default_socket=/var/mysql/mysql.sock". Should these be different like that? I tried making the php.ini setting empty to force it to default but that did nothing nor did changing it to "/tmp/mysql.sock".
Testing PDO outside Drupal seems to work for simple queries at least, testing this works just fins and returns the expected results:
Comment #6
NiklasBr commentedShort update to add that the Mac OS X 10.6.3 update (that included updates to MySQL and PHP) did not change anything.
Comment #7
NiklasBr commentedCan I provide additional information to you anyhow? Databases are not my strong side but I do want to help find a solution to this issue.
Comment #8
lostchord commented@webkenny - The installation procedure is not detecting the configuration error.....looks critical to me.
cheers.
Comment #9
webkenny commented@lostchord, not sure about that. From the looks of the OP's comment it appears Drupal will not allow him to install at all. So it is detecting the error in configuration and not allowing him to proceed.
The only reason I mention that it's probably not critical was that it sounds more like a local machine configuration problem then a Drupal core showstopper or else the entire community would have posted to this issue.
@NiklasBr
For curiousity's sake, can you successfull install an older version from before Alpha?
Comment #10
lostchord commented@webkenny, detection in this case is analgaous to "I detected the brick wall by running into it". This is exactly what appears to have happened, it hit the wall, hard, and is now sitting on the ground talking nonsense..."Are you sure you have the correct username and password?"
I think of these sorts of errors as critical because they prevent the application from being used. A potential user may give up and go try Joomla, or Wordpress, or.... That's not a good result! If this were a commercial application you would have lost a sale.
Installation is part of the core (or at least it should be considered as such!) so this has to be considered a core showstopper...the show never even got on the road!
cheers
Comment #11
NiklasBr commentedI rolled back to a 7.x-dev install I did dec 12 (or about that date), cleared out the database and it installs fine, none of the alpha releases installs though. Today's 7.x-dev release does not install either.
Edit: Since alpha-1 does not work anymore (I think I remember it working) perhaps it is some sort of configuration error. Odd thing though is I consider my system and web server kosher in the sense that I only ever change as little as possible and then I only edit ini/conf files. The httpd.conf and php.ini files are the only files that I have edited unless my memory is failing me.
Comment #12
webkenny commented@lostchord, Good point. I'm on board. Now let's dig in. :)
@NiklasBR, Ok, hm. Let me run an install with a debugger and see where PDO may be involved. I'll try to get to it this weekend.
Comment #13
webkenny commentedNiklas,
Another test I'd like you to run because I've seen something like this before in another area (Drush) is this. Assuming that your $db_url is set to "localhost" can you change that value to the IP address and install again? e.g.
$db_url = user:password@127.0.0.1:3306/mydatabaseI noticed that in the PHP info you provided, mysql and mysqli have no value for default socket and I am wondering if that might be a root cause. Doesn't explain why this one is failing and the others didn't but maybe it will point us to the right place.
-K
Comment #14
jpmckinney commentedOn OS X 10.6, after copying /private/etc/php.ini.default to /private/etc/php.ini, I saw the same error messages as in the OP. I commented out:
And I got rid of the errors. I believe this is because the actual MySQL socket does not match the one in the php.ini, as in #5 above. #5 above could have probably solved his problem by commenting out the line, instead of setting it to an empty string. I've tried setting it to the empty string, too, and it has no effect.
Note that you must restart Apache for changes to take effect:
Comment #15
Crell commentedjpmckinney: Wait. So you mean the problem was the MySQL and PHP that ship with OS X are configured wrong vis a vis each other in the first place? Or is that just wishful thinking on my part? :-)
Comment #16
catchNot much we can do about OSX misconfiguration.
Comment #17
jpmckinney commentedUnless you are running OS X Server, OS X does not ship with MySQL. My MySQL installation puts mysql.sock at /tmp/mysql.sock.
OS X ships with PHP, and by default it has no php.ini. If you copy /private/etc/php.ini.default to /private/etc/php.ini, you will inherit a misconfigured pdo_mysql.default_socket variable.
So, yes, this is a misconfiguration. I don't imagine it is Drupal's responsibility to correct misconfigurations, and anyway, you can't unset a php variable with php_value, which is what would be needed in this case.
Comment #18
catchMight be worth adding to http://drupal.org/Troubleshooting-FAQ maybe? If not we should just close this.
Comment #19
webkenny commentedI originally thought it might be a misconfig. Thanks for the follow-up. I agree. Closing this is fine.
Comment #20
Crell commentedLet's leave open until this error message gets added to the troubleshooting FAQ. Then we can close as fixed. I like seeing green lines in my issue queue. :-)
Comment #21
webkenny commentedMe too. I will own this and get it into the FAQ shortly.
Comment #22
NiklasBr commented@webkenny (#13)
Doing that resulted in a closed connection as expected but if I enabled the user to connect via 127.0.0.1 it went back to normal.
@jpmckinney
Thanks for the info, I'll se what happens with a fresh install.
Comment #23
catchMarked #1005566: Document PDO bug with mysql sockets as duplicate.
Comment #24
Crell commentedwebkenny: Did this ever get documented? If not, it should be so we can close it.
Comment #25
K-Max commentedUpgrading to major since it's been almost a year since the status changed on this. Is anyone else able to finish this update if not webkenny?
By the way for those using macports, the mysql5 package uses mysqld.sock file (by default) in the /opt/local/var/run/mysql5 directory.
The easiest way to get around this is by soft linking it. IE:
sudo ln -s /opt/local/var/run/mysql5/mysqld.sock /tmp/mysql.sockComment #26
webkenny commented@Crell, Happy to get back to this. Where do we think this falls? Error messages or inside the installation pages?
Comment #27
Crell commentedI've never seen this error myself, but the OP suggests its after entering a user name/pass for the database.
We should document (probably just on the site, not in the installer) the solution in #14.
Comment #28
mry4n commentedI just got the same error.
Using #5, #14 and this post as leads, I set two variables in php.ini to /tmp/mysql.sock and that solved my problem:
This post (see: Fix mysql.sock location in php.ini) notes that there is a third setting you should change as well:
mysqli.default_socket = /tmp/mysql.sockAs far as documentation goes, it seems that the moral of the story is to check with
mysqladmin versionto verify the UNIX socket, and set the three variables above accordingly.Comment #29
Crell commentedThe mysql.default_socket and mysqli.default_socket should be irrelevant to Drupal 7, as Drupal 7 and later only uses PDO for all DB connections. Probably not a bad idea to fix those too, but not relevant to Drupal.
Also dropping to normal, since this is just a documentation issue and apparently it's not causing widespread issues.
Comment #30
TomWauman commentedjust to add some extra feedback of a different user: I had the same problem, yet over here it was solved merely by changing the 'host' => 'localhost' in my settings.php to 'host' => '127.0.0.1' for my local server.
Comment #31
devSatan commentedchanging the 'host' => 'localhost' in my settings.php to 'host' => '127.0.0.1' for my local server, helped me too!!! :)
Comment #32
matthewv789 commentedChiming in that I had the same problem, and the same fix from #30 and #31 fixed the problem.
Comment #33
scotwith1tI don't understand, since localhost is just an alias for 127.0.0.1, but I had this same issue and this fixed it for me as well. In our case, the site was built and was running php 5.3 and migrated to a server running php 5.5. Was getting the PDOException: SQLSTATE[HY000] [2002] No such file or directory in lock_may_be_available() error, changed from localhost to 127.0.0.1 in settings.php as mentioned above and voila!
Comment #34
dpiSeems to me this is likely outdated, given version and time since last comment.