New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
danielbachhuber opened this Issue Nov 8, 2016 · 59 comments

Comments

Projects
None yet
@danielbachhuber

danielbachhuber commented Nov 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 8, 2016

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

photodude commented Nov 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Nov 8, 2016

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

danielbachhuber commented Nov 8, 2016

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

@photodude

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 9, 2016

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

photodude commented Nov 9, 2016

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

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Nov 9, 2016

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

danielbachhuber commented Nov 9, 2016

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

@photodude

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 9, 2016

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.

photodude commented Nov 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Nov 9, 2016

👍 Thanks for your help, @photodude

danielbachhuber commented Nov 9, 2016

👍 Thanks for your help, @photodude

@photodude

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 9, 2016

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.

photodude commented Nov 9, 2016

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.

@meatballhat meatballhat self-assigned this Nov 9, 2016

@lesterchan

This comment has been minimized.

Show comment
Hide comment
@lesterchan

lesterchan Nov 10, 2016

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

lesterchan commented Nov 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 10, 2016

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

photodude commented Nov 10, 2016

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

@lesterchan

This comment has been minimized.

Show comment
Hide comment
@lesterchan

lesterchan Nov 10, 2016

@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

lesterchan commented Nov 10, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@szepeviktor

szepeviktor Nov 10, 2016

@danielbachhuber We could shim it for the time being:

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

szepeviktor commented Nov 10, 2016

@danielbachhuber We could shim it for the time being:

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

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 10, 2016

@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.

photodude commented Nov 10, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@arogachev

arogachev Nov 11, 2016

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 commented Nov 11, 2016

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 comment has been minimized.

Show comment
Hide comment
@arogachev

arogachev Nov 11, 2016

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.

arogachev commented Nov 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@szepeviktor

szepeviktor Nov 11, 2016

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)

szepeviktor commented Nov 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@arogachev

arogachev Nov 11, 2016

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.

arogachev commented Nov 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 11, 2016

@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 commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 11, 2016

@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

photodude commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@arogachev

arogachev Nov 11, 2016

@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.

arogachev commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 11, 2016

@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 commented Nov 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 11, 2016

@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)

photodude commented Nov 11, 2016

@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)

@arogachev

This comment has been minimized.

Show comment
Hide comment
@arogachev

arogachev Nov 11, 2016

@photodude It happens now, first time I saw this error was yesterday. You can see according build job and config here.

Thanks for the tip about using group: edge.

arogachev commented Nov 11, 2016

@photodude It happens now, first time I saw this error was yesterday. You can see according build job and config here.

Thanks for the tip about using group: edge.

@szepeviktor

This comment has been minimized.

Show comment
Hide comment
@szepeviktor

szepeviktor Nov 11, 2016

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

@photodude Of course you have to also tell PHP PDO to connect on another socket!

szepeviktor commented Nov 11, 2016

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

@photodude Of course you have to also tell PHP PDO to connect on another socket!

@szepeviktor

This comment has been minimized.

Show comment
Hide comment
@photodude

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Nov 20, 2016

@szepeviktor the socket issue on trusty with mysql(i) PDO can be fixed by changing the DSN host from localhost to 127.0.0.1

but results in

PDOException: SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: NO)

photodude commented Nov 20, 2016

@szepeviktor the socket issue on trusty with mysql(i) PDO can be fixed by changing the DSN host from localhost to 127.0.0.1

but results in

PDOException: SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: NO)
@szepeviktor

This comment has been minimized.

Show comment
Hide comment
@szepeviktor

szepeviktor Nov 21, 2016

You should connect through the socket file not the TCP socket.

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

On November 21, 2016 12:37:10 AM CET, Walt Sorensen notifications@github.com wrote:

@szepeviktor the socket issue on trusty with mysql(i) PDO can be fixed
by changing the DSN host from localhost to 127.0.0.1

but results in

PDOException: SQLSTATE[28000] [1045] Access denied for user
'root'@'localhost' (using password: NO)

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

szepeviktor commented Nov 21, 2016

You should connect through the socket file not the TCP socket.

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

On November 21, 2016 12:37:10 AM CET, Walt Sorensen notifications@github.com wrote:

@szepeviktor the socket issue on trusty with mysql(i) PDO can be fixed
by changing the DSN host from localhost to 127.0.0.1

but results in

PDOException: SQLSTATE[28000] [1045] Access denied for user
'root'@'localhost' (using password: NO)

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

@szepeviktor

This comment has been minimized.

Show comment
Hide comment
@szepeviktor

szepeviktor Nov 21, 2016

I think it is not an uds/tcp problem.

Joomla expects a passwordless root account on Mysql but this new TravisCI container may not have one.

Excuse me.

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

On November 21, 2016 12:37:10 AM CET, Walt Sorensen notifications@github.com wrote:

@szepeviktor the socket issue on trusty with mysql(i) PDO can be fixed
by changing the DSN host from localhost to 127.0.0.1

but results in

PDOException: SQLSTATE[28000] [1045] Access denied for user
'root'@'localhost' (using password: NO)

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

szepeviktor commented Nov 21, 2016

I think it is not an uds/tcp problem.

Joomla expects a passwordless root account on Mysql but this new TravisCI container may not have one.

Excuse me.

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

On November 21, 2016 12:37:10 AM CET, Walt Sorensen notifications@github.com wrote:

@szepeviktor the socket issue on trusty with mysql(i) PDO can be fixed
by changing the DSN host from localhost to 127.0.0.1

but results in

PDOException: SQLSTATE[28000] [1045] Access denied for user
'root'@'localhost' (using password: NO)

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

@jakub300

This comment has been minimized.

Show comment
Hide comment
@jakub300

jakub300 Dec 22, 2016

It looks like there is default password travis for root. You can reset it by running mysql -e 'SET PASSWORD FOR "root"@"localhost" = PASSWORD("");' -uroot in before_install.

jakub300 commented Dec 22, 2016

It looks like there is default password travis for root. You can reset it by running mysql -e 'SET PASSWORD FOR "root"@"localhost" = PASSWORD("");' -uroot in before_install.

@photodude

This comment has been minimized.

Show comment
Hide comment
@photodude

photodude Dec 22, 2016

Thanks @jakub300, that might help has a work around.

Travis has confirmed the socket issues and will be fixing them after the holidays.

photodude commented Dec 22, 2016

Thanks @jakub300, that might help has a work around.

Travis has confirmed the socket issues and will be fixing them after the holidays.

@nijel nijel referenced this issue Mar 2, 2017

Merged

Test against multiple HHVM versions #13041

4 of 4 tasks complete

nijel added a commit to nijel/phpmyadmin that referenced this issue Mar 2, 2017

Try with sudo required
According to some comments in travis-ci/travis-ci#6842 this should
fix the issue with MySQL server.

Signed-off-by: Michal Čihař <michal@cihar.com>

janxious added a commit to expectedbehavior/acts_as_archival that referenced this issue Mar 14, 2017

janxious added a commit to expectedbehavior/acts_as_archival that referenced this issue Mar 14, 2017

@janxious janxious referenced this issue Mar 14, 2017

Merged

Add .travis.yml #28

janxious added a commit to expectedbehavior/acts_as_archival that referenced this issue Mar 14, 2017

@Krinkle

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle commented Mar 14, 2017

Related:

@maartenwodan

This comment has been minimized.

Show comment
Hide comment
@maartenwodan

maartenwodan Mar 30, 2017

Solution for PHP:

  • Create a travisphp.ini in your root (I've had issues with the filename .travisphp.ini before, and also file names with dashes like travis-php.ini do not seem to work).
  • Fill it with the following, when using mysql-5.6:
mysql.default_socket = "/run/mysql-5.6/mysqld.sock"
mysqli.default_socket = "/run/mysql-5.6/mysqld.sock"
pdo_mysql.default_socket = "/run/mysql-5.6/mysqld.sock"
  • Add the following to the .travis.yml:
before_script:
  - phpenv config-add travisphp.ini

maartenwodan commented Mar 30, 2017

Solution for PHP:

  • Create a travisphp.ini in your root (I've had issues with the filename .travisphp.ini before, and also file names with dashes like travis-php.ini do not seem to work).
  • Fill it with the following, when using mysql-5.6:
mysql.default_socket = "/run/mysql-5.6/mysqld.sock"
mysqli.default_socket = "/run/mysql-5.6/mysqld.sock"
pdo_mysql.default_socket = "/run/mysql-5.6/mysqld.sock"
  • Add the following to the .travis.yml:
before_script:
  - phpenv config-add travisphp.ini

n-rodriguez added a commit to jbox-web/ajax-datatables-rails that referenced this issue May 13, 2017

@schaal schaal referenced this issue Jun 5, 2017

Merged

Fix travis build #178

dwbutler added a commit to dwbutler/groupify that referenced this issue Jun 11, 2017

@danepowell

This comment has been minimized.

Show comment
Hide comment
@danepowell

danepowell Jul 14, 2017

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

danepowell commented Jul 14, 2017

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

Krinkle added a commit to Krinkle/mediawiki that referenced this issue Jul 15, 2017

build: Try out Trusty containers
1. Missing package djvulibre-bin: Fixed.
   travis-ci/apt-package-safelist#4036

2. MySQL launch problems: Maybe fixed?
   travis-ci/travis-ci#5837
   travis-ci/travis-ci#6842
@kiklop74

This comment has been minimized.

Show comment
Hide comment
@kiklop74

kiklop74 Jul 20, 2017

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

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

kiklop74 commented Jul 20, 2017

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

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

shioyama added a commit to shioyama/mobility that referenced this issue Jul 22, 2017

shioyama added a commit to shioyama/mobility that referenced this issue Jul 22, 2017

@shioyama

This comment has been minimized.

Show comment
Hide comment
@shioyama

shioyama Jul 23, 2017

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.

shioyama commented Jul 23, 2017

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.

@oliverklee oliverklee referenced this issue Jul 24, 2017

Closed

[META] phpList core phase 2 #125

39 of 39 tasks complete
@benpbolton

This comment has been minimized.

Show comment
Hide comment
@benpbolton

benpbolton Jul 24, 2017

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

benpbolton commented Jul 24, 2017

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

Krinkle added a commit to Krinkle/mediawiki that referenced this issue Jul 29, 2017

build: Update Travis CI config to use fast Trusty containers
We tried this before when Trusty containers were still in Beta,
but the issues we ran into at the time have since been fixed.

1. Missing package djvulibre-bin: Fixed.
   travis-ci/apt-package-safelist#4036

2. MySQL launch problems: Fixed
   travis-ci/travis-ci#5837
   travis-ci/travis-ci#6842

Also add HHVM 3.18 to the test matrix (latest currently preinstalled
version of HHVM).

Change-Id: I2f56e303c01f069207fb086e784e49292ea4eb58

Krinkle added a commit to Krinkle/mediawiki that referenced this issue Jul 29, 2017

build: Update Travis CI config to use fast Trusty containers
We tried this before when Trusty containers were still in Beta,
but the issues we ran into at the time have since been fixed.

1. Missing package djvulibre-bin: Fixed.
   travis-ci/apt-package-safelist#4036

2. MySQL launch problems: Fixed
   travis-ci/travis-ci#5837
   travis-ci/travis-ci#6842

Also add HHVM 3.18 to the test matrix (latest currently preinstalled
version of HHVM).

Change-Id: I2f56e303c01f069207fb086e784e49292ea4eb58

@oliverklee oliverklee referenced this issue Jan 3, 2018

Open

[META] phase 3 #127

7 of 17 tasks complete
@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Apr 13, 2018

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

stale bot commented Apr 13, 2018

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

@stale stale bot added the stale label Apr 13, 2018

@Krinkle

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Apr 13, 2018

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

Krinkle commented Apr 13, 2018

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

@stale stale bot removed the stale label Apr 13, 2018

@shioyama

This comment has been minimized.

Show comment
Hide comment
@shioyama

shioyama May 26, 2018

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

shioyama commented May 26, 2018

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

@shioyama

This comment has been minimized.

Show comment
Hide comment
@shioyama

shioyama May 26, 2018

@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 commented May 26, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@shioyama

shioyama May 27, 2018

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

shioyama commented May 27, 2018

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

@shioyama

This comment has been minimized.

Show comment
Hide comment
@shioyama

shioyama May 30, 2018

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

shioyama commented May 30, 2018

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

@benpbolton

This comment has been minimized.

Show comment
Hide comment
@benpbolton

benpbolton May 30, 2018

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

benpbolton commented May 30, 2018

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

This comment has been minimized.

Show comment
Hide comment
@shioyama

shioyama Jun 2, 2018

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 😖

shioyama commented Jun 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Aug 31, 2018

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

stale bot commented Aug 31, 2018

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

@stale stale bot added the stale label Aug 31, 2018

@stale stale bot closed this Sep 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment