Upgrade to 5.5.53-0ubuntu0.14.04.1 fails to start daemon, due to missing secure_file_priv directory

Bug #1637280 reported by Lonnie Olson on 2016-10-27
44
This bug affects 8 people
Affects Status Importance Assigned to Milestone
mysql-5.5 (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned
Trusty
Undecided
Unassigned

Bug Description

Ubuntu 14.04.1
MySQL 5.5.52-0ubuntu0.14.04.1

MySQL Version 5.5.53-0ubuntu0.14.04.1 changed the default for secure_files_priv from not set to /var/lib/mysql-files
https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/5.5.53-0ubuntu0.14.04.1

This new directory doesn't exist, therefore the daemon will not start.

161027 12:51:30 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/sbin/mysqld: Error on realpath() on '/var/lib/mysql-files' (Error 2)
161027 12:51:30 [ERROR] Failed to access directory for --secure-file-priv. Please make sure that directory exists and is accessible by MySQL Server. Supplied
 value : /var/lib/mysql-files
161027 12:51:30 [ERROR] Aborting

The upgrade should create the new directory required to run the daemon in order to prevent killing the service. Alternatively, this default should not have changed for a minor upgrade in an LTS.

Mauro (mauromol) wrote :

Same problem here. To make MySQL start again, I had to manually type the following commands:

sudo mkdir /var/lib/mysql-files
sudo chown -R mysql:mysql /var/lib/mysql-files/
sudo chmod 700 /var/lib/mysql-files/

For some reason, updating does not trigger that code in mysql-server-5.5-postinst.

I also tried:
sudo dpkg-reconfigure mysql-server-core-5.5
and
sudo aptitude reinstall mysql-sever-core-5.5

with no success.

This was not that easy to find out, because when "sudo service mysql start" is run, no output at all is produced in either of these files:
/var/log/mysql.err
/var/log/mysql.log
/var/log/mysql/error.log
Just the following is printed in /var/log/syslog:

kernel: [ 5613.296491] init: mysql main process (14542) terminated with status 1
kernel: [ 5613.296500] init: mysql main process ended, respawning
kernel: [ 5613.302257] init: mysql post-start process (14543) terminated with status 1
kernel: [ 5613.315931] init: mysql main process (14569) terminated with status 1
kernel: [ 5613.315940] init: mysql main process ended, respawning
kernel: [ 5613.317918] init: mysql post-start process (14570) terminated with status 1
kernel: [ 5613.331260] init: mysql main process (14596) terminated with status 1
kernel: [ 5613.331268] init: mysql respawning too fast, stopped

And to find the actual cause I had to type: sudo mysqld start

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mysql-5.5 (Ubuntu):
status: New → Confirmed
Nish Aravamudan (nacc) wrote :

Hello, and thank you for filing this bug! I will contact the security team to determine if there should be additional changes in the debian scripts to handle the directory creation step.

Changed in mysql-5.5 (Ubuntu):
status: Confirmed → Won't Fix
status: Won't Fix → Invalid
Marc Deslauriers (mdeslaur) wrote :

I can't seem to reproduce the upgrade issue. The postinst is being run correctly in my case.

Is there anything special in your environment that would cause the postinst to fail?

Mauro (mauromol) wrote :

Nothing I'm aware of. Apart from the fact that I disabled the MySQL auto-start at boot, so I start it on demand with "service mysql start". Apart from this, I didn't customize anything in my MySQL installation. As I said, I even tried to reconfigure or reinstall it, but that directory was not created.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mysql-5.5 (Ubuntu Precise):
status: New → Confirmed
Changed in mysql-5.5 (Ubuntu Trusty):
status: New → Confirmed
black (blackborn) wrote :

We have had this bug also. The strange part was that we had a staging and production server set up with chef and only one server had this problem, while everything was identical.

After further checking, we noticed the /var/lib/mysql-files folder was missing from the server with erratic behaviour. As chef didn't deployed a new version, we think the automatic updates did something erratic.

black (blackborn) wrote :

btw. manually creating the folder with mysql:mysql ownership resolved our problem (or adding secure_file_priv="" in the my.cnf)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers