Percona Server with XtraDB

mysql_install_db not working properly with percona server

Reported by Jay Janssen on 2013-04-17
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Percona Server
Status tracked in 5.6
5.1
Undecided
Unassigned
5.5
Critical
Alexey Bychko
5.6
Critical
Unassigned
Percona XtraDB Cluster
Critical
Alexey Bychko

Bug Description

I am installing Percona server on a clean Centos 6.4 VM that is i686 with yum from the Percona apt repo:

Running Transaction
  Installing : Percona-Server-shared-55-5.5.30-rel30.2.500.rhel6.i686 1/9
  Installing : 1:perl-Pod-Escapes-1.04-130.el6_4.i686 2/9
  Installing : 3:perl-version-0.77-130.el6_4.i686 3/9
  Installing : 1:perl-Module-Pluggable-3.90-130.el6_4.i686 4/9
  Installing : 4:perl-libs-5.10.1-130.el6_4.i686 5/9
  Installing : 1:perl-Pod-Simple-3.13-130.el6_4.i686 6/9
  Installing : 4:perl-5.10.1-130.el6_4.i686 7/9
  Installing : Percona-Server-client-55-5.5.30-rel30.2.500.rhel6.i686 8/9
  Installing : Percona-Server-server-55-5.5.30-rel30.2.500.rhel6.i686 9/9
chown: invalid user: `mysql'
Cannot change ownership of the database directories to the 'mysql'
user. Check that you have the necessary permissions and try again.
Percona Server is distributed with several useful UDF (User Defined Function) from Maatkit.
Run the following commands to create these functions:
mysql -e "CREATE FUNCTION fnv1a_64 RETURNS INTEGER SONAME 'libfnv1a_udf.so'"
mysql -e "CREATE FUNCTION fnv_64 RETURNS INTEGER SONAME 'libfnv_udf.so'"
mysql -e "CREATE FUNCTION murmur_hash RETURNS INTEGER SONAME 'libmurmur_udf.so'"
See http://code.google.com/p/maatkit/source/browse/trunk/udf for more details
  Verifying : 1:perl-Pod-Escapes-1.04-130.el6_4.i686 1/9
  Verifying : Percona-Server-shared-55-5.5.30-rel30.2.500.rhel6.i686 2/9
  Verifying : 3:perl-version-0.77-130.el6_4.i686 3/9
  Verifying : 1:perl-Module-Pluggable-3.90-130.el6_4.i686 4/9
  Verifying : Percona-Server-server-55-5.5.30-rel30.2.500.rhel6.i686 5/9
  Verifying : Percona-Server-client-55-5.5.30-rel30.2.500.rhel6.i686 6/9
  Verifying : 1:perl-Pod-Simple-3.13-130.el6_4.i686 7/9
  Verifying : 4:perl-libs-5.10.1-130.el6_4.i686 8/9
  Verifying : 4:perl-5.10.1-130.el6_4.i686 9/9

Installed:
  Percona-Server-server-55.i686 0:5.5.30-rel30.2.500.rhel6

I get an error when I try to start mysql, because /var/lib/mysql/mysql does not have any system tables in it. I'm guessing the mysql_install_db failed here. Can anyone confirm this?

Download full text (3.9 KiB)

Possible regression from:

revno: 463.1.1 [merge]
     fixes bug: https://launchpad.net/bugs/710799
     committer: Alexey Bychko <email address hidden>
     branch nick: bug710799-5.5
     timestamp: Thu 2013-03-07 19:45:40 +0700
     message:
       fix for bug 710799, version 5.5
       [-] disabled uncongitional manual creation of /var/lib/mysql/*
       [+] added conditional call of mysql_install_db, only for clean installation, but not for upgrade
       [+] added debug possibility for %post
     diff:
     === modified file 'build/percona-server.spec'
     --- build/percona-server.spec 2013-02-26 16:40:25 +0000
     +++ build/percona-server.spec 2013-03-07 12:45:40 +0000
     @@ -710,13 +710,16 @@
      fi

      %post -n Percona-Server-server%{product_suffix}
     -
     +if [ X${PERCONA_DEBUG} == X1 ]; then
     + set -x
     +fi
      # ATTENTION: Parts of this are duplicated in the "triggerpostun" !

      mysql_datadir=%{mysqldatadir}
      NEW_VERSION=%{mysql_version}-%{release}
      STATUS_FILE=$mysql_datadir/RPM_UPGRADE_MARKER

     +if [ $1 -eq 1 ]; then
      # ----------------------------------------------------------------------
      # Create data directory if needed, check whether upgrade or install
      # ----------------------------------------------------------------------
     @@ -734,8 +737,11 @@
         # If the directory exists, we may assume it is an upgrade.
         echo "MySQL RPM upgrade to version $NEW_VERSION" >> $STATUS_FILE
      fi
     -if [ ! -d $mysql_datadir/test ] ; then mkdir $mysql_datadir/test; fi
     +if [ ! -d $mysql_datadir/test ]; then
     + mkdir $mysql_datadir/test;
     +fi
     +%{_bindir}/mysql_install_db --rpm --user=%{mysqld_user}
     +fi
      # ----------------------------------------------------------------------
      # Make MySQL start/shutdown automatically when the machine does it.
      # ----------------------------------------------------------------------
     @@ -761,26 +767,19 @@
      usermod -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true

      # ----------------------------------------------------------------------
     +# Initiate databases if needed
     +# ----------------------------------------------------------------------
     +# ----------------------------------------------------------------------
     +# Upgrade databases if needed would go here - but it cannot be automated yet
     +# ----------------------------------------------------------------------
     +
     +# ----------------------------------------------------------------------
      # Change permissions so that the user that will run the MySQL daemon
      # owns all database files.
      # ----------------------------------------------------------------------
      chown -R %{mysqld_user}:%{mysqld_group} $mysql_datadir

      # ----------------------------------------------------------------------
     -# Initiate databases if needed
     -# ----------------------------------------------------------------------
     -
     -# ----------------------------------------------------------------------
     -# Upgrade databases...

Read more...

The bug is:

=================================================================

if [ $1 -eq 1 ]; then
# ----------------------------------------------------------------------
# Create data directory if needed, check whether upgrade or install
# ----------------------------------------------------------------------
if [ ! -d $mysql_datadir ] ; then mkdir -m 755 $mysql_datadir; fi
if [ -f $STATUS_FILE ] ; then
 SERVER_TO_START=`grep '^SERVER_TO_START=' $STATUS_FILE | cut -c17-`
else
 SERVER_TO_START=''
fi
# echo "Analyzed: SERVER_TO_START=$SERVER_TO_START"
if [ ! -d $mysql_datadir/mysql ] ; then
 mkdir $mysql_datadir/mysql;
 echo "MySQL RPM installation of version $NEW_VERSION" >> $STATUS_FILE
else
 # If the directory exists, we may assume it is an upgrade.
 echo "MySQL RPM upgrade to version $NEW_VERSION" >> $STATUS_FILE
fi
if [ ! -d $mysql_datadir/test ]; then
        mkdir $mysql_datadir/test;
fi
%{_bindir}/mysql_install_db --rpm --user=%{mysqld_user}
fi
# ----------------------------------------------------------------------
# Make MySQL start/shutdown automatically when the machine does it.
# ----------------------------------------------------------------------
# NOTE: This still needs to be debated. Should we check whether these links
# for the other run levels exist(ed) before the upgrade?
# use chkconfig on Enterprise Linux and newer SuSE releases
if [ -x /sbin/chkconfig ] ; then
        /sbin/chkconfig --add mysql
# use insserv for older SuSE Linux versions
elif [ -x /sbin/insserv ] ; then
        /sbin/insserv %{_sysconfdir}/init.d/mysql
fi

# ----------------------------------------------------------------------
# Create a MySQL user and group. Do not report any problems if it already
# exists.
# ----------------------------------------------------------------------
groupadd -r %{mysqld_group} 2> /dev/null || true
useradd -M -r -d $mysql_datadir -s /bin/bash -c "MySQL server" \
  -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true
# The user may already exist, make sure it has the proper group nevertheless
# (BUG#12823)
usermod -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true

=======================================================================================

when %{_bindir}/mysql_install_db --rpm --user=%{mysqld_user} is called

the user won't exist since it is a clean install.

It should be moved to its original position.

The workaround would be to manually do

groupadd -r %{mysqld_group} 2> /dev/null || true
useradd -M -r -d $mysql_datadir -s /bin/bash -c "MySQL server" \
  -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true
# The user may already exist, make sure it has the proper group nevertheless
# (BUG#12823)
usermod -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true

before doing yum install (in case of clean install)

Changed in percona-xtradb-cluster:
importance: Undecided → Critical

As per the reporter,

doing :

mysql_install_db --user=mysql + service mysql start

manually should also do.

This is because the users/groups are created anyways, only the mysql_install_db fails.

Changed in percona-server:
importance: Undecided → Critical
status: New → Confirmed
Changed in percona-xtradb-cluster:
status: New → Confirmed

Fix released in Percona-XtraDB-Cluster 5.5.30-23.7.4.404

Changed in percona-xtradb-cluster:
status: Confirmed → Fix Released
Changed in percona-xtradb-cluster:
assignee: nobody → Alexey Bychko (abychko)
Changed in percona-xtradb-cluster:
milestone: none → 5.5.30-23.7.4-2
Alexey Kopytov (akopytov) wrote :

Apparently the fix doesn't work as intended or is incomplete, see bug #1174426.

Jaime Sicam (jssicam) on 2013-05-11
tags: added: i31262
Roel Van de Paar (roel11) wrote :

Does this bug require further followup for 5.6 GA? Setting 56qual ftm until we're sure.

tags: added: 56qual
Ignacio Nin (ignacio-nin) wrote :

Not reproducible in 5.6, setting to Invalid as is fixed in all other versions.

Ernestas (ernetas) wrote :

I amm able to reproduce this for Percona 5.6 on clean Ubuntu 12.04.3 virtual machines.

Ernestas,

Can you provide more details of this - logs etc.? The bug was reported for
CentOS/RPM and was due to regression from https://launchpad.net/bugs/710799. Also, 710799 was not ported to PS 5.6 (but it is in PXC 5.6 though, along with fix of 710799), so this issue is not there for RPM either (for PS5.6).

Waiting for more details (including exact 5.6.x version used) from Ernestas.

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

Duplicates of this bug

Other bug subscribers