I get this error whenI go to my drupal 7 site:

PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in lock_may_be_available() (line 165 of /home/xxxxxxxx/public_html/includes/lock.inc)...

Too many connections? How do I fix this?



Technonow’s picture

In Sites/default/settings.php try changing 'localhost' to ''

It's easier for the programme to find the numbers than the words.

Not sure why, but it does work.

davidk2’s picture

I am trying to find solution...

juroon’s picture

Put whatever domain you're using at the moment into your base URL in settings.php. If you're working with a test URL before activating your domain name, set the base URL to your test domain. You'll have to remember to put it back when you activate your domain.

Also if you're using a test URL, you'll need the name of your site folder in sites to be default and not your final domain name.

cooldeeponline’s picture

Worked for me... thanks!

# $cookie_domain = '.example.com';
# $cookie_domain = 'localhost';	
   $cookie_domain = '.testwebsite.com';

Make sure to always start the $cookie_domain

* with a leading dot, as per RFC 2109.

Karll’s picture

how would this apply to a multisite install?

markosaurus’s picture

It's not easier for the program to find anything.

"localhost" will just be an alias of "" in the same way that "www.yourdomain.com" would be an alias of "254.432.456.554" or something else online. It's just a human-friendly version of the same thing.

If the alias is missing, drupal won't find the database though.

nally’s picture

Here is the reason why switching to might be helping some folks...

from the MySQL documentation:

On Unix, MySQL programs treat the host name localhost specially, in a way that is likely different from what you expect compared to other network-based programs. For connections to localhost, MySQL programs attempt to connect to the local server by using a Unix socket file. This occurs even if a --port or -P option is given to specify a port number. To ensure that the client makes a TCP/IP connection to the local server, use --host or -h to specify a host name value of, or the IP address or name of the local server.

Christian Nally - B.C., Canada - http://sticksallison.com

fikifir’s picture

Open Advance option then change "localhost" to ""
Thanks Mr Nally

darol100’s picture

Works thanks

- Darryl Norris
Be Connected: Website | Twitter | LinkendIn | GitHub

robdroy’s picture

Changing from localhost to worked for me. Thanks!

eawheeler’s picture

After my last post in December 2015, I continued to experience the PDOException error. So, I returned to digging for clues that would point me to the source of the problem. My inspection of the mysqld.log file revealed several lines indicating errors including:

InnoDB: ERROR: the age of the last checkpoint is 9443079,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
InnoDB: mmap(137363456 bytes) failed; errno 12
InnoDB: Fatal error: cannot allocate memory for the buffer pool

Research seemed to suggest that increasing the log file size would resolve these errors. To do so, I executed the following steps. If you follow them, please backup your system first!!! If you don't, and your site crashes irrevocably, don't say I didn't warn you.

  1. Verified that innodb_fast_shutdown settings was 1 not 0 or 2. You can check by entering the following command within MySQL
    • show variables like ‘%innodb_fast_shutdown%’;
  2. If it is set to 2 or 0, enter the following command. You want to make sure that fast shutdown is set to 1.
    • SET GLOBAL innodb_fast_shutdown = 1;
  3. If you changed the value, stop MySQL and check for errors in the mysqld.log (exit out of mysql first!)
    • sudo service mysqld stop
    • sudo tail -n 50 /[your path to mysqld.log]/mysqld.log
  4. Copy the old ib_logfile0 and ib_logfile1 log files located in the directory /var/lib/mysql (on my flavor of Linux). You may need to use sudo since these files may be owned by the mysql user. You are moving them for two reasons: 1) as a backup in case something with the configuration goes wrong; and 2) the files need to be recreated because they must be resized.
    • cd /var/lib/mysql
    • sudo mv ib_logfile0 /[your desired directory]/ib_logfile0
    • sudo mv ib_logfile1 /[your desired directory]/ib_logfile1
  5. Edit the MySQL configuration file (my.cnf) to increase the log file size. Specific size will vary depending on your needs. The default value is 5 megabytes. I increased the size of mine to 128 megabytes. To do so, add the following line to the [mysqld] section of the file. If a [mysqld] section doesn't exist, add it.
    • innodb_log_file_size = 128M
  6. Restart MySQL.
    • sudo service mysqld restart
  7. Inspect the log file for errors.
    • sudo tail -n 50 /var/log/mysqld.log
  8. The following lines will appear normally when the system recreates the log files (since they were moved out of the directory in step 4).
    • InnoDB: The log sequence number in ibdata files does not match
    • InnoDB: the log sequence number in the ib_logfiles!

Since I performed the above reconfiguration in mid February 2016, I haven't experienced any PDOException errors or errors within the MySQL log files. So, I now believe that this was my primary problem all along. While it's possible that the localhost vs. issue was a contributing factor, I'm fairly skeptical. I may revert to localhost in the future to test my theory.

Pedro-del-gado’s picture

Works for me, thanks a lot.

Mamouri’s picture

Arwym’s picture

I am having a similar or identical error ever since I uploaded my Drupal 7 site to my hosting provider's server. Locally, I wasn't having any problems, so I assumed it could be cache-related, because none of the solutions above worked for me. I cannot access anything on the site; it's always the same error. I also truncated the cache tables in the database to see if that helped. Nothing so far. I am in a real hurry right now, and don't know what else to do.

Is there anything else, caching-related, that I could try? Since I cannot access the GUI, I cannot use the administrative options for clearing the site's caches. Is there anything else I can do? Again, I am using Drupal 7.9, and all my modules were updated and tested before uploading the installation to the production server.

kbrinner’s picture

I have drupal commerce working locally on my machine but am getting the same error after uploading my site to my hosting provider. I uploaded the files and imported the db from my local machine, and I also adjusted the settings.php file as needed for the db.

This is the error I get:


The website encountered an unexpected error. Please try again later.
Error messagePDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) in lock_may_be_available() (line 167 of [path to my subdomain]/includes/lock.inc).

Tried making the change suggested above (in settings.php, change localhost to and got a very similar error after this change:


The website encountered an unexpected error. Please try again later.
Error messagePDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 111 in lock_may_be_available() (line 167 of [path to my subdomain]/includes/lock.inc).

Switched from in settings.php, and then tried changing the base url in settings.php to the staging site I'm setting up and got the same error as the first error


The website encountered an unexpected error. Please try again later.
Error messagePDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) in lock_may_be_available() (line 167 of [path to my subdomain]/includes/lock.inc).

kbrinner’s picture

When I uploaded my site to a different hosting provider, I had no problems, and I followed exactly the same procedure for both hosting providers. Of course the first hosting provider (where it didn't work) claims the issue is on my side (could be) but it is suspicious that I had no problem with a different hosting provider. It works using KnownHost, not working using APlus.

obutuz’s picture

Am getting the same error , Drupal 7, any solution yet/ I tried changing "localhost" to "" but still nothing. Help a bro!

PDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 111 in lock_may_be_available()

gloscon’s picture

Sometimes this happens when you run out of disk space and hence mysql doesn't start.

camerongreen’s picture

I've seen this same error in a number of places, and I'm yet to see a solution so would appreciate anyone above who has solved it posting.

PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in lock_may_be_available() (line 167 of /home/content/foo/bar/html/includes/lock.inc).

Lots of answers without any explanation of why they will work (which often a sign that they won't work).

Drupal 6 was working fine, but when I upgrade to 7 I get this error. I got this after transferring a working site on my local machine to my hosting provider which is something I've seen come up a few times. I can connect fine from the command line to mysql using exactly the same parameters, just not in the settings.php. The server is not on the localhost so the solution won't work, though I did try swapping the host name for the IP just to check, no luck.

Edit: OK I worked it out, was simple in the end and was a user error. I'd used some old code from my D6 settings.php which was based on the old url connection strings. The new D7 settings file was overwriting this at the bottom of the file for development but not production. I pulled down a pristine copy of the latest D7 did a vim diff on my settings.php and the default.settings.php and the error became evident.

jonline’s picture

I had the similar issue... After doing some investigation I found the problem with host name. So I have changed it to the host name from localhost and it resolve the issue. Hope this will help...

HFlame7’s picture

In my case, the process/service "mysqld" had stopped (not sure why). But starting it up again solved it.

a.knutson’s picture

Thanks a lot for posting this solution. It worked in my case as well! Although I had to '/etc/init.d/mysql restart' for ubuntu

commonpike’s picture

It means, as it says, "Can't connect to local MySQL server".

"lock_may_be_available" is basicly the first database call drupal makes. if it cant connect there, it will fail there first, and that has nothing to do with a lock.
so mysql isnt running, or your config is wrong, or the webserver cant connect to the database server, or something like that.

if there is something wrong with a lock, it will return a different error.



doliveros’s picture


WisTex’s picture

I also have MySQL issues with my WordPress websites periodically (i.e. can't reach the MySQL database), so based on what you are saying, it sounds like, at least in my case, the database has gone down.

Since both WordPress and Drupal recover automatically within a couple minutes, I assume the MySQL service went down and then was restarted.

Karll’s picture

This is the error I am getting about once a week to two weeks, once I restart it is fine but eventually reoccurs. I am running a multisite configuration with about 8 sites running independent databases. (each site has its own database) This is installed on Amazons EC2(Ubuntu 12.04) and running on a micro instance, Each time this has happened all sites cannot connect - On one site I changed the database configuration from "localhost" to but still wont connect for that site as well.

I suspect it may be MYSQL crashing and have never had this issue on other Drupal installs. If I figure out what is causing it I will post back

Error Message:
Error The website encountered an unexpected error. Please try again later. Error messagePDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) in lock_may_be_available() (line 167 of /var/www/drupal/includes/lock.inc).

a.knutson’s picture

I'm not so sure it has anything to do with the fact that it's a multi site install. I'm having the exact same scenario reoccur on a similar setup. I'm running multiple EC2 micro instances for a few different drupal sites. Two of my EC2's have the mysql crashing issue that you have described. Once or twice a week the PDO error is thrown and doing "sudo service mysql status" on the server's terminal shows that mysql stopped. If I restart mysql, all is good for another 3-7 days. Inevitably it crashes all over again and I'm repeating the process.

Please keep informed if you have found a solution Karll. Thanks for posting this!

ykyuen’s picture

I am getting the same error even for single drupal instance on a EC2 micro instance with MariaDB. So i guess it is not related to multi-site.

Vale80’s picture

I'm getting an error which I believe to be very similar to the most of this topic.

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1226 User 'MYDBUSER' has exceeded the 'max_queries_per_hour' resource (current value: 150000) in lock_may_be_available() (line 167 of /MYDOMAIN/includes/lock.inc).

I'm using a MySQL db and Drupal 7.16.

I noticed that the error comes out when I'm using Views and a Block created from Views. And after I have installed Userpoints with all the Contributed Modules available. Maybe this can help. :)

I have tried to follow all the steps mentioned above but I'm still receiving this error and my hosting is not helping me because the error is on my site.

Does anyone have a solution please?

dberlind’s picture


I have Drupal 7 installed on a Ubuntu-based EC2 Microinstance and am having the exact same problem. In my case, the site is going down almost daily. I'm desperate for a solution if anybody has figured this out.



Tux Love’s picture

Same here, again on an EC2 Microinstance that I use for testing a production site that runs fine on a 'proper' server.

I don't have an answer (yet), but note these comments in this link on the AWS forums:

  • "I can confirm the replication of this issue. I have attempted this on multiple micro instances and they all display the same error. Websites function properly for a while, but all ultimately fail with the mysql error."
  • "Moving to a higher grade Instance does the job. I am not sure if there are certain setting then can make a micro instance work."

I set a tail -f /var/log/mysql/error.log and get this following every crash:

130713 14:33:07 [Note] Plugin 'FEDERATED' is disabled.
130713 14:33:07 InnoDB: The InnoDB memory heap is disabled
130713 14:33:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130713 14:33:07 InnoDB: Compressed tables use zlib
130713 14:33:07 InnoDB: Initializing buffer pool, size = 10.0M
130713 14:33:07 InnoDB: Completed initialization of buffer pool
130713 14:33:07 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1247297728
130713 14:33:07  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1247300088
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is A9700
130713 14:33:07  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
130713 14:33:08  InnoDB: Rolling back trx with id A95AF, 1 rows to undo
130713 14:33:08  InnoDB: Waiting for the background threads to start

InnoDB: Rolling back of trx id A95AF completed
130713 14:33:08  InnoDB: Rollback of non-prepared transactions completed
130713 14:33:09 InnoDB: 5.5.31 started; log sequence number 1247300088
130713 14:33:09 [Note] Server hostname (bind-address): ''; port: 3306
130713 14:33:09 [Note]   - '' resolves to '';
130713 14:33:09 [Note] Server socket created on IP: ''.
130713 14:33:09 [Note] Event Scheduler: Loaded 0 events
130713 14:33:09 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.31-0ubuntu0.12.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

Can anyone spot any clues in there?

ddarras2012’s picture

Issue on our end evidently was chron jobs or something else taking up system resources - surfaced before.

bazza14’s picture

I've just had this problem on a Drupal 7 site with Blacknight shared hosting. The basic problem is, as others have said elsewhere on this thread, that it can't connect to the database. In my case it was because this hosting company assigns the data base name, user and localhost when you create the database. Changing these settings in /sites/default/settings.php fixed the problem so try checking with your hosting company that you have these set correctly.

$databases = array (
  'default' => 
  array (
    'default' => 
    array (
      'database' => 'db121xxx_mysite',
      'username' => 'u121xxx_auser',
      'password' => 'xxxxxxxxxx',
      'host' => 'mysqlxxxxxint.xx.blacknight.com',
      'port' => '3306',
      'driver' => 'mysql',
      'prefix' => '',

DeNelo’s picture

Thanks! The mysql host did the trick!

unnikrishnan’s picture


Restarting Mysql fix this error for me.

Also check mysql error logs for any error that might cause the crashing of the process.

Unnikrishnan B.

jayprakasht’s picture

I faced similar issue and error while installing Drupal 7 on Ipage hosting site. But after trying some permutations and combinations
I could resolve this issue by changing the localhost to correct mysql hostname

Go to your cpanel – then mysql database – find the generate code column and hit the black board icon – that should give you your hostname!!!!

Good Luck

michaelversus’s picture

The solution for me was to change the host from "localhost" to "db21.xxxxx.com" and port to "3306" under the advanced settings during the installation
you can see the host in the PHPmyAdmin page.

Good Luck!

bluesky_still’s picture

this disk is full or mysqld is shutdown for me

sharif.elshobkshy’s picture

PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) in lock_may_be_available()

sudo service mysql start fixed the issue for me.


malovanets’s picture

That's obvious, however many people (me as well) have this error as recurring. You can't just monitor whether your mysql server crashed or not and restart it every single day.

jessewwilson’s picture

I was getting this error, similar but not exactly the same however I found the solution in this thread after 8 1/2 hours of banging my head off the wall.

"PDOException: SQLSTATE[HY000] [2002] Connection timed out in db_table_exists() (line 2761 of...."

The problem does seem to be in the settings.php file. I was trying to migrate a local build from acquia dev desktop to a 1&1 hosted site. All of the settings were correct but apparently the location within the settings file was the problem? Everything else seems to be the same.

I moved the db array block from the end of the file (the way that it's created by acquia dev desktop) to before the "$update_free_access = FALSE;" code.

Very strange, but I'm relieved just the same.

robinthakur’s picture

Ok, this has happened every single time I have deployed to Production on Go Daddy, has anyone worked out what is causing it?

  • I clear my cache
  • Tar up my files
  • Export all my database from MySQL
  • FTP my tarred up files
  • extract the tarred files
  • Import my database
  • upload a settings.php file to the root of the sites/default containing the Godaddy MySQL host i imported to and the username, password and database.
  • I browse to the site and I get this error every single time
  • If I browse to install.php it detects that drupal is already installed, but then if I click on view current site, I get the same error

Usually it seems to just go away, but this time it won't., no matter what I do. Any suggestions? I develop using Acquia Drupal's MAMP stack, could this be causing it?

Any help is gratefully received, Rob

Jaypan’s picture

I use this method, works every time:

1) Install the Backup and Migrate module on the existing installation
2) Take a backup using this module
3) Copy the entire Drupal file system (minus settings.php) to the new server
4) Install Drupal as a fresh installation with this file system
5) Enable the Backup and Migrate module
6) Restore the database in this new installation using the backup from step 2

er.pushpinderrana’s picture

I also followed this approach and it work for me.

robinthakur’s picture

Thanks to both of you for your advice, I might just do that in future! I found that it is Acquia Drupal leading to these issues, specifically the setttings.php format which basically stops the site connecting to the database in MySQL. I took a "vanilla" Drupal installation (from my NAS!) and looked at the settings.php file which had a completely different layout, copied it to my hosted copy, changed the db values, and it worked first time. This is rather annoying that it is not more widely known. Had I known I'd have such issues deploying an Acquia Drupal site, I'd have used another method to build my dev environment, but I think Jaypan's suggestion get's around the issue

GiorgosK’s picture

my error was similar to all above but SQLSTATE different number
PDOException: SQLSTATE[42000] [1044] Access denied for user
and it had to do with the fact that the user was not actually permitted to access the database
and this happened when renaming database through the CPANEL/phpmyadmin rename operation !!

Zollcore’s picture

I've had about as much fun with this one as a lot other people seem to of had from all the threads with no concise answer.
My answer may be of no assistance because it will probably only work in certain environments. My environment is a local XAMPP install.
I tried it all: localhost,, different ports, different users, restarts.... No change.
I was staring at settings.php, thinking of what else to attempt. Heck, lets just go with my local IP 192.168.1.##. Save, refresh, boom. Everything was back to the way it used to be.
Why did it require this change? No idea, I didn't change any settings. Just shutdown XAMPP, left for the day to come back with a morning of troubleshooting.
I am not looking forward to migrating upon completion of this site.

Hope this helps some of you out, and you don't have dynamic lan IPs.....

alexharries’s picture

Very strangely, this (changing "localhost" to "") has also worked for me on Greengeeks shared hosting.

I'm VERY confused...!!

Jaypan’s picture

I just had this error suddenly, without having made any changes. I contacted my host, in this case, it was a bug in Cpanel, and required a MySQL restart.

alt36’s picture

A comment which might clarify something that's come up a few times here: for MySQL on linux, connecting via localhost is *not* the same as connecting via (even though they will both resolve to "this computer"). With MySQL, connecting to "localhost" will connect via a local unix socket, whereas connecting to uses a network connection. Which one you should use will, as always, depend on local configuration - but they are *not* the same, and there are plenty of reasons why one might work and the other fail.

See e.g. http://dev.mysql.com/doc/refman/5.1/en/connecting.html

liansu’s picture

I am clueless now, after this error happened few times, I think it must be a way to solve but I didn't get yet, so I really need some guidance.

It recovered by restarting MySQL at first time, and Changing from localhost to, port to 3306 works in second time, but I still getting this error and recovered after restarting MySQL:

The website encountered an unexpected error. Please try again later.
Error messagePDOException: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 111 in lock_may_be_available() (line 167 of /var/drupal/includes/lock.inc).

I really don't want to repeating this process all over again as I always need ask someone's help on. So can anyone tell me what I should do step by step?


cm60’s picture

In terminal the command I use is service mariadb restart or you might have to use another like:

/etc/init.d/mysqld restart

Or if you are using Cpanel or something else just search for docs on how to restart

trumpetmercenary’s picture

I just had this issue after a new Drupal install.

The problem: MySql wasn't running.

I'm an idiot.

Sandip Mondal’s picture

PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) in lock_may_be_available() (line 167 of /home/xxxxxxx/public_html/xxxxx1/includes/lock.inc).

Please help me. how to solve?

Wtower’s picture

As many other posts stated, most obvious steps apply, like eg. checking that mysql is in fact up and running. Apart from that, there is another reason when socket connection fails arbitrarily.

Many VPS hosting providers impose a maximun number of files limit. A unix socket connection is essentialy a file. Although technically a tcp connection is for linux a file descriptor, as a socket connection is, since it is a kernel handle, the imposed limits often exclude the tcp connections.

For example, the Virtuozzo virtualization software controls the number of open files with the `numfile` setting. From their documentation:

`numfile`: the number of "files" in use including real files, sockets, and pipes. The barrier should be set equal to the limit. The configuration of this parameter doesn't affect security and stability of the whole system or isolation between Containers. Its configuration affects functionality and resource shortage reaction of applications in the given Container only.

This setting does not affect imposed kernel limits, therefore `ulimit` command does not report this limitation. For Virtuozzo, to take a look at this limit you can issue: `sudo cat /proc/user_beancounters | grep numfile`. If, or more correctly, when the VPS hits the limit, probably because there are many web sites or many socket connections, you start getting this exact random error.

This is why the recommended solution to replace `localhost` with `` works with this case. Although semantically both are the same, by convention the former establishes a socket connection to most default configurations, whereas the latter establishes a tcp connection, not affected by the vps limit.

Of course the socket connection is faster in performance, as the socket does not have the networking overhead. But if a site is small in traffic, the overhead is negligible and usually goes unnotices. Otherwise moving on to a dedicated solution might be the way to go.

eawheeler’s picture

Last week I first encountered a very similar error to the ones described in this thread. Since then, it's reoccurred once. Restarting MySQL or the server resolves it, temporarily. I've been running the server in its present configuration since August of 2015, so it's a puzzle to me why the error is popping up now. Though it doesn't seem like a robust fix, I'm going to try the solution that several have suggested by modifying settings.php to read 'host' => '' . I'm also changing the port setting from port => '' to port => '3306'

My server configuration is:

Amazon EC2 t2.micro
1 GB swap file
Amazon Linux 4.1.10
Apache 2.4.16
MySQL 5.5.45
PHP 5.5.30
Drupal 7.41

The specific error I receive is:

PDOException: SQLSTATE[HY000] [2002] No such file or directory in lock_may_be_available() (line 167 of /var/www/html/includes/lock.inc).

I thought that the error might have been caused by a lack of available memory. However, I checked free memory after the second occurrence, and I was using no more than 2/3 system memory and was barely using swap. $base_url is set to my FQDN. I tried setting 'host' to the FQDN but the site wouldn't load after a MySQL restart. I'm thinking this might be part of my problem.

I'm currently running with 'host' => '' and port => '3306' . I will report back if my site returns with the error again, or smooth sailing if I don't get it in the next two weeks.

I do have a question. What other settings need to be in place in order to set 'host' to the FQDN?

Jaypan’s picture

PDOException: SQLSTATE[HY000] [2002] No such file or directory in lock_may_be_available() (line 167 of /var/www/html/includes/lock.inc).

This error shows up when MySQL is not available for whatever reason. This can mean a misconfiguration in your system, or it can mean a problem in MySQL. Since your system is working, it's more likely that it was a problem with MySQL than with your configuration.

eawheeler’s picture

It's been over three weeks since my PDOException errors, and I've had no recurrence. I changed the configuration file lines in /sites/default/settings.php from:

'host' => 'localhost',
'port' => '',


'host' => '',
'port' => '3306',

dirkjohnson’s picture

I went in circles with this for a while. When I moved my install, I created the database user and password directly in MySQL and then changed the password in settings.php. When I created the MySQL password, I used an '&' in the password, following my usual practice of using symbols as well as numbers and upper and lower case letters. Then I had the "aha!" moment of realizing that the unescaped '&' was probably a bad idea....

Most people probably have a different issue. But that solved my problems. I post this for the one other person who wasn't thinking it through when creating their database password.

asiby’s picture

To solve this, simply add the following to your DB settings inside settings.php. And update the path to the DB socket.

'unix_socket' => '/Applications/MAMP/tmp/mysql/mysql.sock'

Hopefully this helps.

Live long ... and prosper!

ragavendra_bn’s picture

I had a multisite installation and commenting the line like below helped me in the settings.php file

# 'unix_socket' => '/var/lib/mysql/mysql.sock',

Apparently the sock file was not in the path and I assume that to be causing the error.

ThilinaM’s picture

restart mysql server then will fix the problem

shakyak’s picture

Worked for me thanks

hiramanpatil’s picture

I have tried below options.

'host' => '',

'unix_socket' => '/Applications/MAMP/tmp/mysql/mysql.sock'

'unix_socket' => '/var/lib/mysql/mysql.sock',

at the end restart mysql server but still getting errors.

I am getting below error messages randomly.

The website encountered an unexpected error. Please try again later.
PDOException: SQLSTATE[HY000] [2002] Connection refused in Drupal\dblog\Logger\DbLog->log() (line 102 of core/modules/dblog/src/Logger/DbLog.php).
Drupal\dblog\Logger\DbLog->log(3, '%type: @message in %function (line %line of %file).', Array) (Line: 136)
Drupal\Core\Logger\LoggerChannel->log(3, '%type: @message in %function (line %line of %file).', Array) (Line: 65)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->onError(Object) (Line: 92)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->onException(Object, 'kernel.exception', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.exception', Object) (Line: 216)
Symfony\Component\HttpKernel\HttpKernel->handleException(Object, Object, 1) (Line: 70)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 649)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)


Uncaught exception thrown in session handler.

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) ); Array ( [:db_condition_placeholder_0] => -82QG1FvI9ES4Q8X9nPGa66IHXVviEbhzOrS6O6K_YA ) in Drupal\Core\Session\SessionHandler->write() (line 84 of /var/www/html/viperks-front/code/core/lib/Drupal/Core/Session/SessionHandler.php).


The website encountered an unexpected error. Please try again later.
PDOException: SQLSTATE[HY000] [2002] Connection refused in Drupal\Component\DependencyInjection\PhpArrayContainer->createService() (line 79 of /var/www/html/viperks-front/code/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php).


Warning: PDOStatement::execute(): Error reading result set's header in Drupal\Core\Database\Statement->execute() (line 59 of /var/www/html/viperks-front/code/core/lib/Drupal/Core/Database/Statement.php).

I am using Drupal 8 on Ubuntu 14.04.


asiby’s picture

Hello hiramanpatil

Are you using MAMP or MySQL on a unix socket, if that's the case (and only in such case), you should figure out the full path to the unix socket and use it in your DB configuration as specified earlier in this thread.

One way to determine if you need to use the unix_socket option or not is to try to run drush cc all or drush pml. If it runs successfully, then you don't need to configure the unix_socket.

For the error that says MySQL server has gone away, everytime I have encountered this error, I solved it by increasing the MySQL max_allowed_packet size.

I have no clue about the other errors.

Hopefully this will help you.


Live long ... and prosper!

kadiiski’s picture

I realised that my mysql service was stoped. It might be your case too.

senpAi95’s picture

Literally everything was good. mysql was up and running. Checked by introducing bind-address in my.cnf to changing it back-and-forth from localhost to The error got changed from SQLSTATE[HY000][2002] to SQLSTATE[HY000][2003] respectively. Nothing was working.I literally spent almost 10 hours to figure out this.

Solution: In my case, mysql.sock provides a tunnel between client and server mysql to interact. It only gets created when mysql server is up and running. My issue was the path where it was checking for the mysql.sock, didnt exist in that directory. So i had to create  a symbolic link from that directory to the path where it actually existed. YES, it worked...

command to create a symbolic link

ln  - s   /path/where/it/actually/exists/mysql.sock   /path/where/it/is/looking/for/mysql.sock   

asiby’s picture

Hello senpAi95,

No need to create a symbolic link. Just change the configuration of whatever is trying to access MySQL to ensure that it is using the proper socket path. You can't just go and alter the host computer just because some sites needed the socket to be in a specific location. In the case of a Drupal configuration, it's probably going to be in the settings.php file and looking like ...

'unix_socket' => '/blah/blah/blah/mysql.sock'

Just edit it to make it point to the valid socket file.

Live long ... and prosper!

senpAi95’s picture

In my settings.php there is nothing like unix_socket... I think i need to write in databases array and I tried it with pdo = path/sock  but it was not much of a help previously. So had to do a symbolic link...could have changed the path in my.cnf itself, but i dont know in what all files I need to update the path. Couldn't take that risk.

asiby’s picture

Hello senpAi95

The message didn't quite get across.

  1. A path to a MySQL socket file is something that will exist (or not) in you server or computer based on how MySQL has been installed. MySQL could use either a Unix Socket or a TCP/IP socket. To put it simply, a Unix Socket is a file based communication mechanism whereas a TCP/IP is a network based thing. A Unix Socket cannot be accessed from another machine. Also, Unix sockets are a little bit faster as you don't have the tcp-overhead.
  2. Usually, there is no 'unix-socket' key anywhere in any settings.php for Drupal. You have to add it yourself in the database array just like in the example below. 
    $databases = array (
      'default' => 
      array (
        'default' => 
        array (
          'database' => 'db121xxx_mysite',
          'username' => 'u121xxx_auser',
          'password' => 'xxxxxxxxxx',
          'host' => 'mysqlxxxxxint.xx.blacknight.com',
          'port' => '3306',
          'driver' => 'mysql',
          'prefix' => '',
          'unix-socket' => '<path-to-your-mysql-socket>',
  3. Now this point is very important, and I sense that I did not emphasize enough on it... You SHOULD NEVER modify the location of your applications Unix Socket to please other applications. Try keeping your computer's dignity intact. The only exception is when the apps that needs the Unix Socket cannot be configured and it's a matter of life and death. But that's a hint that the application is not well designed. The same applies to polluting your system with symbolic links that point to MySQL's Unix Socket for the same reason.

  4. You need to check if your MySQL is actually using a Unix Socket. For that, run the following at the command line where MySQL is installed (assuming you are using anything by Windows LOL) ...

  5. mysql -u root -p --execute "show variables;" | grep socket

    This should return something similar to the following lines where you can see that in my case MySQL is installed by MAMP (MAMP PRO to be precise) and that the socket file is somewhere deep inside MAMP folder structure.

    performance_schema_max_socket_classes	10
    performance_schema_max_socket_instances	230
    socket	/Applications/MAMP/tmp/mysql/mysql.sock

    As you can see, in my case, the Unix Socket is located at /Applications/MAMP/tmp/mysql/mysql.sock 

  6. Update the settings.php using the unix-socket key with the value found at step 5. If your system is not using a Unix Socket at all, then using localhost or as host could be sufficient but I am not sure about that.

Hopefully this helps.

    Live long ... and prosper!