Issues running MySql in a Snap on TravisCI

snapcraft
1

I’m writing some integration tests for a Snap that contains a MySql database and I’m having difficulties getting it to run on TravisCI.

Obviously, this seems more like a TravisCI issue but I was wondering if there are any known issues with getting MySql running inside a Snap in a CI or containerized test environment. It tunrs just fine on my local and in a prod-like environment.

MySql tries to start but then dies with a May 21 00:22:11 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[15388]: * MySQL server PID file could not be found! error.

It then tries again with a slightly different error but still fails:

May 21 00:22:21 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e systemd[1]: Started Service for snap application slurm.mysql.
16666May 21 00:22:21 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16023]: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
16667May 21 00:22:21 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16023]: 2020-05-21T00:22:21.819810Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
16668May 21 00:22:21 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16023]: 2020-05-21T00:22:21.890772Z 0 [ERROR] Can't change data directory owner to mysql
16669May 21 00:22:21 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16023]: 2020-05-21T00:22:21.890812Z 0 [ERROR] Aborting
16670May 21 00:22:21 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16023]: NOT NEW INSTALL
16671May 21 00:22:21 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16023]: Starting MySQL
16672May 21 00:22:22 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16023]: . * The server quit without updating PID file (/var/snap/slurm/common/var/run/mysql/mysql.pid).
16673May 21 00:22:22 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e systemd[1]: snap.slurm.mysql.service: Main process exited, code=exited, status=1/FAILURE
16674May 21 00:22:23 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e slurm.mysql[16913]: * MySQL server PID file could not be found!
16675May 21 00:22:23 travis-job-3bb86edc-4914-4066-96be-8f71aaf9ca2e systemd[1]: snap.slurm.mysql.service: Unit entered failed state.

I already opened an issue with the Travis folks… Anyone here have any ideas?

2

The relevant part appears to be this:

2020-05-21T00:22:21.890772Z 0 [ERROR] Can't change data directory owner to mysql
2020-05-21T00:22:21.890812Z 0 [ERROR] Aborting

In general, you shouldn’t expect a chown call to work from within a snap, so if your snap is making a chown call that would be the problem.

Looking at this old MySQL bug report, it sounds like the code in question happens when the MySQL data directory already exists when it tries to initialise a new database.

Based on that, you might be able to reproduce the bug locally by running mkdir -p /var/snap/slurm/common/var/lib/mysql (assuming that’s where your MySQL instance stores its data) prior to installing your snap.

3

Perfect - I will check into that.

Also - we chown a few different things during the install hook of our Snap because we are running daemons as the snap daemon user which doesn’t have access to most things within the Snap. Is there a better way of handling this?

For example, the snap daemon user needs to read config files and write log files to snap common which is owned by root by default.