"Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'"

[danielbachhuber]

My builds are failing on this error:

mysql -e 'CREATE DATABASE wp_cli_test;' -uroot
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

See https://travis-ci.org/wp-cli/wp-cli/jobs/174318358 for a representative job.

This issue is specific to Travis CI and new within the last ~8 hours. Happy to help debug further if you'd like to point me in a direction.

[photodude]

Also seeing this on the Container-based Ubuntu Trusty Public Beta

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Reference #5695

[danielbachhuber]

Thanks @photodude. Didn't realize infrastructure changes rolled out today.

[photodude]

@danielbachhuber Looks like your running Trusty beta. drop dist: trusty from your travis.yml to fix the issue. @szepeviktor made that change.

[danielbachhuber]

@photodude Right. Can we expect the issue to be fixed any time soon, or should I revert in all of the relevant places?

[photodude]

I would revert for now for live repos needing to do continuous testing since Trusty is beta. Test your repo with trusty beta in a separate repo and plan to migrate some time after Q1-17 when it's officially released.

Trusty likely doesn't benefit you unless you need something like HHVM 3.9+ (current hhvm is 3.15) which is trusty specific.

[danielbachhuber]

👍 Thanks for your help, @photodude

[photodude]

You are welcome @danielbachhuber, Glad your up and testing again. Hopefully the trusty issues can be sorted out soon (I'm hoping it will be faster for testing HHVM)

PS Please keep this issue open until it's resolved on Container-based Trusty Beta.

[lesterchan]

I symlinked the socket and it works provided you have sudo required in your .travis.yml

sudo mkdir -p /var/run/mysqld
sudo ln -s /run/mysql-5.6/mysqld.sock /var/run/mysqld/mysqld.sock

[photodude]

@lesterchan symlinking the socket like that doesn't work on the Container-based Trusty Beta as sudo is disabled on the Containers.

[lesterchan]

@photodude ops, yeap forgot to add that.

You will get the socket error regardless whether you are using container-based trusty or not. For me, I have sudo required and hence it is not a container-based trusty. So the symlink works for me.

language: php
sudo: required
dist: trusty
group: edge

[szepeviktor]

@danielbachhuber We could shim it for the time being:

alias mysql='mysql --socket=/run/mysql-5.6/mysqld.sock'

[photodude]

@lesterchan I have no issue with the socket on sudo required trusty. For me this is an issue only with the Container-based Trusty Beta.

[arogachev]

I'm facing the same issue. Fixed it by installing and using MySQL 5.6:

addons:
  apt:
    packages:
      - mysql-server-5.6
      - mysql-client-core-5.6
      - mysql-client-5.6

But along with it we must change user to root because travis is not supported. Also default is MySQL 5.5 in both precise and trusty. We don't want to bump the version just to fix it. So I'm not happy with this solution, looking for better one. Will try to use alias.

[arogachev]

This:

alias mysql='mysql --socket=/run/mysql-5.5/mysqld.sock'

didn't work for me. Gives the same error:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

I checked the contents of both /run and /var/run folders with ls -la, there are no mysql related files or folders at all.

[szepeviktor]

Please see our successful builds https://travis-ci.org/wp-cli/wp-cli/builds/174754228

+36204242498
Ezen a készüléken sok az elütés.
Elnézést!

On November 11, 2016 6:17:50 AM CET, Alexey Rogachev notifications@github.com wrote:

I'm facing the same issue. Fixed it by installing and using MySQL
5.6:

addons:
 apt:
   packages:
     - mysql-server-5.6
     - mysql-client-core-5.6
     - mysql-client-5.6

But along with it we must change user to root because travis is not
supported. Also default is MySQL 5.5 in both precise and trusty. We
don't want to bump the version just to fix it. So I'm not happy with
this solution, looking for better one. Will try to use alias.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#6842 (comment)

[arogachev]

To continue using MySQL 5.5 and prevent upgrading to 5.6 I installed mysql-server-5.5 package (seems like it's missing):

addons:
  apt:
    packages:
      - mysql-server-5.5

Now the error is gone. As a temporary fix this is OK, but I hope it will be fixed in a better way, for example by having this package installed by default.

Also, even it's MySQL 5.5, we can't use travis user which was successfully used in precise dist`:

mysql -e 'CREATE DATABASE yiitest;';
ERROR 1045 (28000): Access denied for user 'travis'@'localhost' (using password: NO)

So additionally it needs to be replaced with root.

[photodude]

@arogachev I installed mysql 5.6 since that is how I have sudo required trusty set up and working. Already using mysql root as that is required for the sudo required trusty, I only changed the lines to switch to the Container-based Trusty Beta.

This is a Container-based Trusty Beta specific issue

@szepeviktor 's suggestion of aliasing the socket does work arround this issue, but reveals the issue noted in #6853

[photodude]

@szepeviktor for your workaround on wp-cli you have to also specify dist: precise under the php 5.3 as Trusty only default supports php 5.4+

Additionally, I noticed with the alias workaround there are PDO issues

PDOException: SQLSTATE[HY000] [2002] No such file or directory

[arogachev]

@photodude Maybe there are some nuances on Container-based Ubuntu Trusty, but I get the same error on Standard Ubuntu Trusty using config:

dist: trusty
sudo: required

Without additional installation I mentioned above the error persists.

[photodude]

@arogachev we do not have this issue on sudo required trusty for Joomla or with doctrine dbal (note only hhvm is tested via sudo required trusty) I'm only seeing this issue with Container-based Trusty Beta.

Is this a new issue you are seeing on sudo required trusty or something from a while back?

[photodude]

@arogachev I ran a new test, I can confirm what you are seeing in sudo required trusty. Seems to be in issue if the group is not set to edge
add this line to the top of your travis.yml and the issue should go away as it did for my edge test

group: edge

Although I'm still getting a related PDOException issue on php with group: edge
PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

[danepowell]

Travis support indicates that this should no longer be an issue with the latest Trusty builds... we'll test and see.

[kiklop74]

Started 3 builds and one of them failed like this. See for yourself:

https://travis-ci.org/kiklop74/moodle-local_xray/jobs/255790946

[shioyama]

Also seeing this having been switched over to Trusty. I don't really understand why Travis bumped everyone to Trusty without resolving this issue first, since I have to imagine it will affect so many users.

I've just switched back to Precise with dist: precise for now.

[benpbolton]

Just fought a bit with this. Here was our solution:

Ensure:

services:
  - mysql

... is present in your .travis.yml since the docs say:

Travis CI environments do not start services by default, to make more RAM available to build scripts.

... annnnd... if you want to ensure that the service had enough time to spin up before you start interacting with it, you might give something like this a go:

    # Wait for mysql service to respond
    - which mysql && until mysql -u root -e "show status" &>/dev/null; do sleep 1; done

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[Krinkle]

For wikimedia/mediawiki, containers (sudo: false) with MySQL (services: - mysql) now work fine as-is and without additional workarounds or timers.

[shioyama]

Suddenly seeing these errors again... anybody else having issues with this?

[shioyama]

@benpbolton's solution seems to just leave some builds in a hung state, e.g. this one. Mysql service never comes up. Didn't have this issue until yesterday.

[shioyama]

Seems to have fixed itself, not seeing any more failures.

[shioyama]

Never mind, still happening. Is no-one else having this issue? Really annoying to have to restart builds all the time.

[benpbolton]

hey @shioyama , we definitely haven't run into this in the last year or so :( Perhaps suspect odd behavior for postgres vs mysql env? Eg. perhaps the mysql service doesn't launch when DB=postgres or something similar? So the

    - which mysql && until mysql -u root -e "show status" &>/dev/null; do sleep 1; done

is just looping forever in that context. You could test if $DB == mysql before waiting for it if that was helpful

[shioyama]

No the hung state happens on mysql builds... but thanks for the idea. For now I'll just see if it goes away naturally or if it will require manual intervention 😖

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 24 hours. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

[adteulade]

Hey we were having the same issue since yesterday. After some investigations it appears that the ubuntu trusty isn't somehow the default OS used for builds. The one used by default seems to be Ubuntu Xenial.

Using :

dist: trusty

in your .travis.yml fixed this issue (after language: php).
The weirdest thing is that when restarting master build, tests were working but if we were creating a new branch from master without changing anything we had the issue

[BanzaiMan]

https://travis-ci.community/t/prs-started-failing-on-6-12/3707/2

We are moving to Xenial as the default, and we do not start DB by default.

https://blog.travis-ci.com/2019-04-15-xenial-default-build-environment#1-services-support

You need to explicitly instruct that it is needed.

services:
  - mysql