commit 0ddd79ed3f9579f96541721991b7a4ea8d108997
Author: Petr Malik <email address hidden>
Date: Wed Feb 18 18:16:20 2015 -0500
Delete mysql error log file as root on restore
The Problem:
The current code let's Python manage the MySQL error log file generated
during the root password reset on backup restore (see bug/1419995).
The problem is that the database service may assume ownership of that
file in the process. The 'restricted deletion' policy dictates that
only owners (and the directory owner) can delete temporary files.
If this happens the cleanup step fails halting the whole
restore process.
NOTE: Not all datastores necessarily exhibit this behavior
(i.e. taking ownership of the log file).
It has been confirmed on Percona 5.5 running under Ubuntu Linux.
The Reproduction (important):
This issue is masked in the default testing (redstack) environment.
Redstack (in 'scripts/functions_qemu') sets 'GUEST_LOGDIR'
to the 'log_dir' value from 'etc/trove/trove-guestagent.conf.sample'
which happenns to be '/tmp/'.
Later in 'scripts/files/trove-guest.upstart.conf' assumes the ownership
of that directory: "chown GUEST_USERNAME:root GUEST_LOGDIR"
effectively hiding this issue (see bug/1423760).
The temporary directory would generally not be owned by the trove user
in a production environment.
In order to reproduce this issue in Redstack set 'GUEST_LOGDIR' to
some directory other than '/tmp', like '/var/log/trove/',
kick-start Percona 5.5 (remember to remove the cached
image if any) and run instance backup/restore or int-tests.
The Solution:
Do not let Trove do the cleanup on the error log file.
Force-delete the file as root, logging but not raising any exceptions.
Reviewed: https:/ /review. openstack. org/157972 /git.openstack. org/cgit/ openstack/ trove/commit/ ?id=0ddd79ed3f9 579f96541721991 b7a4ea8d108997
Committed: https:/
Submitter: Jenkins
Branch: master
commit 0ddd79ed3f9579f 96541721991b7a4 ea8d108997
Author: Petr Malik <email address hidden>
Date: Wed Feb 18 18:16:20 2015 -0500
Delete mysql error log file as root on restore
The Problem:
The current code let's Python manage the MySQL error log file generated
during the root password reset on backup restore (see bug/1419995).
The problem is that the database service may assume ownership of that
file in the process. The 'restricted deletion' policy dictates that
only owners (and the directory owner) can delete temporary files.
If this happens the cleanup step fails halting the whole
restore process.
NOTE: Not all datastores necessarily exhibit this behavior
(i.e. taking ownership of the log file).
It has been confirmed on Percona 5.5 running under Ubuntu Linux.
The Reproduction (important): functions_ qemu') sets 'GUEST_LOGDIR' trove-guestagen t.conf. sample' files/trove- guest.upstart. conf' assumes the ownership
This issue is masked in the default testing (redstack) environment.
Redstack (in 'scripts/
to the 'log_dir' value from 'etc/trove/
which happenns to be '/tmp/'.
Later in 'scripts/
of that directory: "chown GUEST_USERNAME:root GUEST_LOGDIR"
effectively hiding this issue (see bug/1423760).
The temporary directory would generally not be owned by the trove user
in a production environment.
In order to reproduce this issue in Redstack set 'GUEST_LOGDIR' to
some directory other than '/tmp', like '/var/log/trove/',
kick-start Percona 5.5 (remember to remove the cached
image if any) and run instance backup/restore or int-tests.
The Solution:
Do not let Trove do the cleanup on the error log file.
Force-delete the file as root, logging but not raising any exceptions.
Tested on: MySQL 5.5/5.6 and Percona 5.5/5.6
Change-Id: I9dd6ed543a01ec c4f84065ea4bf37 37960de6e24
Closes-Bug: 1423759
Related-Bug: 1423760