Cannot "show variables" on trusty/sudo:false with MySQL 5.7

[john-latham]

I install MySQL 5.7 using:

addons:
  apt:
    sources:
      - mysql-5.7-trusty
    packages:
      - mysql-server

I want to inspect MySQL variables using

- mysql -e 'show variables'

...but this fails with:

ERROR 1682 (HY000) at line 1: Native table 'performance_schema'.'session_variables' has the wrong structure

This suggests incomplete upgrade to MySQL 5.7 (from 5.6 which comes on trusty) but I cannot upgrade using:

- sudo mysql_upgrade
- sudo service mysql restart

..because there is no sudo.

Using sudo:required is not a solution because I'm attempting to debug a test failure which only happens on the sudo:required environment, and in order to do that I want to compare all the MySQL variables between sudo:false and sudo:required environments.

I suggest as a fix that the sudo mysql_upgrade is added to whatever code processes the mysql-server addons, although this is possibly not under control of travis.

[BanzaiMan]

Do you have a build log URL that shows the problem you are describing here?

[john-latham]

Yes, but it's not public:

https://s3.amazonaws.com/archive.travis-ci.com/jobs/81095252/log.txt

This shows the error:

[0K$ mysql -e 'show variables'

ERROR 1146 (42S02) at line 1: Table 'performance_schema.session_variables' doesn't exist

I believe this to be a symptom of an incompletely upgraded mysql, but I cannot complete the upgrade without sudo.

[BanzaiMan]

So, did the issue with dist: trusty + sudo: required start recently (in particular, around the time we upgraded the image a little over a week ago https://blog.travis-ci.com/2017-06-21-trusty-updates-2017-Q2-launch), or this combination never worked?

[BanzaiMan]

Towards the end of the mysql-server installation, we see:

Configuration file '/etc/apparmor.d/usr.sbin.mysqld'
 ==> Deleted (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
 ==> Keeping old config file as default.
Installing new version of config file /etc/init.d/mysql ...
update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode
runlevel:/var/run/utmp: No such file or directory
No directory, logging in with HOME=/
mkdir: cannot create directory ‘//.pyenv’: Permission denied
mkdir: cannot create directory ‘//.pyenv’: Permission denied
..
 * MySQL Community Server 5.7.18 is started
Processing triggers for ureadahead (0.100.0-16) ...
Setting up mysql-server (5.7.18-1ubuntu14.04) ...
Processing triggers for libc-bin (2.19-0ubuntu6.13) ...
W: --force-yes is deprecated, use one of the options starting with --allow instead.

I'm guessing that the apt addon falls short on updating the package for whatever reason.

[john-latham]

We only tried this today, so I don't know if it is new. MySQL 5.7 has only been possible using apt-sources since it was whitelisted on Apr 20:

travis-ci/apt-source-safelist@41a6948

I made a minimal example demonstrating this behaviour:

https://github.com/john-latham/travis-ci-7992
https://travis-ci.org/john-latham/travis-ci-7992

It seems to produce somewhat unreliable results. Sometimes MySQL does not start (we saw this also on sudo:required) and sometimes MySQL does start but the show variables fails.

[BanzaiMan]

I vaguely remember AppArmor being problematic, but the details escape me.

[osahner]

I might add a new error:

{
  "language": "java",
  "jdk": "oraclejdk8",
  "services": [
    "mysql"
  ],
  "addons": {
    "apt": {
      "sources": [
        "mysql-5.7-trusty"
      ],
      "packages": [
        "mysql-server",
        "mysql-client"
      ]
    }
  },
  "sudo": "required",
  "before_install": [
    "sudo mysql_upgrade --force",
    "sudo mysql -e ...",
    "sudo service mysql restart"
  ],
  "group": "stable",
  "dist": "trusty",
  "os": "linux"
}

The following packages have unmet dependencies:
 mysql-client : Depends: mysql-client-5.5 but it is not going to be installed
 mysql-server : Depends: mysql-server-5.5 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

[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