I just imported a site from MyKinsta into DevKinsta and once the import completes, I click to open the site and I get the following error.
Warning : mysqli_real_connect(): (HY000/2002): No such file or directory in /www/kinsta/public/therapistcomdev/wp-includes/wp-db.php on line 1653
No such file or directory
Error establishing a database connection
I am able to open the Database manager from DevKinsta without issue.
I have searched for posts with similar errors here and no solution was found.
I have tried changing to wp-config file db settings to those found on the site info page in devKinsta
I have restarted all the Docker containers
I have deleted and re-imported the site
I have verified that there is plenty of available disk space on the mariadb docker instance
I have connected to the db with MySQLWorkbench using the credentials and specific port in Site info
This issue started after we had Kinsta support change the document root on the sites themselves. Prior to this change the root had been setup as ā/providersā (this is where wordpress was installed) we had the document root changed to ā/ā and all wordpress files moved up to ā/ā and now when importing the site I get the above error.
We made the change to the document root entirely because the document root in DevKinsta is set to ā/ā and changing it in NGINX does not persist. Now we are faced with this issue. Thanks for your assistance.
I noticed you have a custom ENV based configuration.
Iām not sure what this looks like within DevKinsta for you after the Pull, but it sounds like it isnāt routing to the correct environmentās wp-config file (maybe you need to add the .local domain somewhere in your ENV logic/code?).
As far as troubleshooting this, I would try temporarily using a default wp-config.php to try and connect the site to the database and if that works, then the issue is likely with how your Environments are being routed.
Please let us know if none of this works out; I tried reproducing this and got a similar error when WordPress doesnāt get any database credentials for the connection.
Thanks for the reply Kevin. I have confirmed that I am getting to the correct wp-config file, If I change the host from localhost to 127.0.0.1 the error changes to āconnection refusedā because the user connection is only allowed from ālocalhostā so I know the request is getting to MySQL.
This all started when the document root path was changed so I have to believe that factors in but I cant possibly see how. The live sites in MyKinsta are working as expected even after this changeā¦ its only affecting DevKinsta, any ideas?
Ok I think I have found the issue but I am not sure how to resolve it or how the issue occurred when being imported into DevKinsta?
The /run/mysqld/mysqld.sock file is empty so Im wondering if its permissions on that file?
drwxrwxrwx 1 mysql mysql 4096 Jan 6 11:26 .
drwxr-xr-x 1 root root 4096 Sep 26 2020 ā¦
-rw-rw---- 1 mysql mysql 2 Jan 6 11:26 mysqld.pid
srwxrwxrwx 1 mysql mysql 0 Jan 6 11:26 mysqld.sock
but wouldnāt that affect adminer as well?
Ive tested that this issue exists outside of wordpress by setting up a single php file with the connection string info, which also fails with the same error.
This is an odd one; weāll need to troubleshoot it from the bottom up to figure out exactly whatās going on.
Can you create a blank WordPress install in MyKinsta then Pull that into DevKinsta? If this works as expected, the problem is probably with the Dev site. If it doesnāt work, then the problem is likely with the Docker containers. If that were the case I would recommend trying to delete all of the Docker containers and reinstalling DevKinsta (assuming you donāt have any work done locally yet)
There could also be the chance that it has something to do with how the ports are being routed on your system but I havenāt had enough experience with this to be sure.
Trying the same process on a different OS or machine would be a possible troubleshooting step as well.
If all else fails please share your OS/version and Docker Version. Iām assuming youāre using the latest release of DevKinsta if it isnāt asking you for updates. Weāll do what we can to try and reproduce this on our end to troubleshoot with you.
I have pulled some of our other sites into DevKinsta without any issues.
I have been able to reproduce the issue on 2 different machines, 1pc and 1mac. Same results both times.
I feel like this is something related to the docker containers as well but specific to this one site. I have the latest version on DevKinsta
Docker is 4.3.1
Windows 10
Im going to uninstall everything and see if that makes a difference.
Okay sounds good; I mentioned changing the DB_HOST because I noticed itās set to devkinsta_db when you pull a normal WP configuration. Localhost and 127.0.0.1 also donāt work for me.
Iām curious of what response you get with that; it might be that localhost/127.0.0.1 just arenāt being routed to Docker.
Awesome; I donāt fully understand it, I just noticed thatās how my other sites were set up.
Iām guessing using devkinsta_db instead of localhost avoids some common conflicts between local development environments. It probably has to do with how the hosts file is set up, but Iām not 100% certain. It just seems DevKinsta is able to replace the DB_HOST for normal configurations but isnāt able to do it automatically for this site.
Iām honestly very surprised this hasnāt shown up before in the forums! Iām glad itās working, though!
I really do appreciate it Ive been wracking my brains over this one haha. Is there some way we can get setting the host in our build script/import process?
Youāre welcome!
Iām not entirely sure how that would be done; I think since your site is already set up to use specific environment variables based on where itās loading from, you could just set the DB_HOST for the DevKinsta environment to be ādevkinsta_dbā with the correct credentials. Iām not 100% sure how that is behaving for you in DevKinsta, though.
Otherwise, you could make a feature request for the Pull to to look for wp-config constants within selected files. Right now it only replaces within wp-config.php.
Actually after thinking about it, it should be enough to just make that appropriate change in the local specific wp-config file. That should persist with new imports.
