mysql_install_db not working properly with percona server

Bug #1170024 reported by Jay Janssen
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Invalid
Undecided
Unassigned
5.1
Invalid
Undecided
Unassigned
5.5
Fix Released
Critical
Alexey Bychko
5.6
Invalid
Undecided
Unassigned
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Fix Released
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?

Tags: i31262

Related branches

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :
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...

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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.

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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
Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

As per the reporter,

doing :

mysql_install_db --user=mysql + service mysql start

manually should also do.

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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
Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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
Revision history for this message
Alexey Kopytov (akopytov) wrote :

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

Jaime Sicam (jssicam)
tags: added: i31262
Revision history for this message
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
Revision history for this message
Ignacio Nin (ignacio-nin) wrote :

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

Revision history for this message
Ernestas (ernetas) wrote :

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

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

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).

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

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

information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Roel Van de Paar (roel11) wrote :

Closing out this open bug for 5.6 by s/incomplete/invalid/ until counter proof is shown.

tags: removed: 56qual
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-923

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2939

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.