By austinm08 on

Drupal 6.14

This is about to drive me absurd. I've put in the database information, and I get the following error.
I've read through the same forum posts several times trying to find a solution.

I put in 127.0.0.1 for "localhost" and it still returns me with an error, although a different one.
I'm surprised more people aren't posting about this problem. I can't see why my situation is special at all.
I've changed the permission on the settings files to "666" (default.settings.php and settings.php) already, if that's even related.

"Failed to connect to your MySQL database server. MySQL reports the following message: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2).

Are you sure you have the correct username and password?
Are you sure that you have typed the correct database hostname?
Are you sure that the database server is running?

For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider."

⋅ Categories: Drupal 6.x

Comments

VM’s picture

VM commented

the settings.php file needs to be writeable and 666 isn't writable. Drupal will change the permissions on the file when installation is complete.

Whether the above will fix your issue or not, I don't know. However if drupal can't write to the settings.php file then it can't store the information in the $db_url string you enter during install.

austinm08’s picture

austinm08 commented

I guess I don't understand. According to FileZilla, 666 shows Read and Write on Public, Group, and Owner.

However, when I go back to the file permissions afterward, it shows Public "Write" as unchecked again (664).

So, what IS writeable, then?

VM’s picture

VM commented

If the install was never set up the file should be 777

dman’s picture

dman commented

The questions to start are obvious ones, but they've got to be asked because you left out all that background.
The questions are in fact asked on that help page, but you've not answered them.
- Do you even have a database server?
- is it running?
- What port is it running on (see my.cnf)
- what OS?
- Does it use a /tmp.mysql.sock (see my.cnf) or something else?
(OSX installed the mysql.sock in a different place than expected at one point, and I saw similar errors until I used a different distro of PHP)
- Have you created the database with correct credentials as instructed?
- can you log in to that DB normally (commandline, phpmyadmin or GUI) with those credentials?

And from your description, why would localhost give you a different error from 127.0.0.1 ? And what is the error? "a different one" is obsfucatory.
That sounds screwy unless you created the DB credentials to limit to one and not the other. Which is possible in MySQL I guess, but you'd have to refer to the instructions you followed to do that. Generally just username@% is OK for localhost development.

- is it in fact localhost development or an ISP? Details like that are important.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

austinm08’s picture

austinm08 commented

I should've provided you with more details, I was just feeling really ancy. I'll answer what I can..

The domains are through GoDaddy, hosting is through NetworkSolutions.

Database server, as in do I have a database? Well, my client goes through Network Solutions (.com) for his hosting, and I have set up the database there. And.. as far as I know, it's up and running. Yes, I can log into it through phpmyadmin.
One thing I should note is that the database seems to be completely empty at this point. Is that normal?

The last time I installed Drupal for a site I figured out commandline long enough to get what I needed done.. but I don't have a lot of experience with it other than that.

I would see your .cnf about the questions regarding the port and .sock, but I'm not really sure what your .cnf is. :/

One thing that might be important is that I created the databases through NetworkSolutions' online GUI (I guess you'd call it that).. not through anything else. I didn't seem to have to go through everything on this page:
http://drupal.org/getting-started/6/install/create-database

The DB name is: potterservicesdb
Server name is: mysqlv10
Username: potterservicesdb

Is it correct that I should use the DB name and username (and password) to enter in the Drupal installation (and not the "server name")?

Server OS? Small-Unix.. I guess.
My PC is Windows 7.

Thanks much for the help you guys have provided thus far.

VM’s picture

VM commented

If on a host you wouldn't use 127.0.0.1

At the top of phpmyadmin or in your hosts documentation should be the database server location. That is what you use. If localhost, great. That makes it easy. However the settings.php still needs to be able to be written to.

austinm08’s picture

austinm08 commented

It says "Server: Localhost via UNIX socket".

I keep changing the permissions, everything will stay "writeable" except for "Public".

(left: read, center: write, right: execute)

Owner
x x x

Group
x x x

Public
x _ x

VM’s picture

VM commented

Change the permissions on the default folder, then on the settings.php file if necessary. The permissions should stick.

I just use the CHMOD numbers not tickboxes in filezille.

austinm08’s picture

austinm08 commented

I was using the numbers, too.

I set the permissions for the entire folder, 777.
Checked it immediately after, it was 775 (no write for "Public").

VM’s picture

VM commented

775 may work. Host may not allow 777. Don't know what effect doing what you've done to an entire folder will have.

austinm08’s picture

austinm08 commented

Well, I meant the "default" folder. Not the folder containing all of Drupal.

But... I still get the same error..

Images removed that showed db connection information

VM’s picture

VM commented

puts me out of ideas. Maybe someone else will have more.

austinm08’s picture

austinm08 commented

Hmm.. someone's on their A-game tonight.. images removed quick.

Well, thanks for your help, sir. :) I appreciate it.

VM’s picture

VM commented

I removed the images.

gregrli’s picture

gregrli commented

I just worked on this problem for 2 hours. What I finally found out is that since GoDaddy is hosted externally (their databases), you have to type in the database IP 92.213.324.1 or whatever it is where the "local host" usually is.

austinm08’s picture

austinm08 commented

Greg!

Thank you. I assumed that since the database is on the same server Drupal is on, it didn't need the IP from "another server"....
but I guess I was wrong.

I snagged the server IP and replaced "localhost" under Advanced Settings with it, and voila!

Thank you again!
Austin

dman’s picture

dman commented

If the database host name is "mysqlv10" then that is the value you should put in the field labelled "database host".
Not localhost.
This should be documented somewhere in the information supplied to you from technical support or basic docs where they give you information about how to connect to your DB server.

Most cheap hosts have their databases on separate machines. That's what the config option is there for.
"localhost" is mostly a term referring to developing on your "local" "host" machine. The one your keyboard is plugged in to.

Plenty of other dedicated servers (VMs mainly) will also default back to using localhost as a shorthand ("local" to your login session or server processes), but if you are using a low-budget hosting solution, this is unlikely.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

Djaps’s picture

Djaps commented

Error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)'
Was the error driving me crazy on my stage server, i solved it couple of months ago, by removing services like mysql pdo and apache and reinstalling everything, which resolved the problem temporary, and today it showed again, blocking my progress, and I had to get to the bottom of it, and solved it by adding ​SWAP​ memory to the staging server.

https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubun...

Let's hope it's a permanent solution. :)