MySQL Bugs: #21949: RHEL4 installation bug

Bug #21949	RHEL4 installation bug
Submitted:	31 Aug 2006 15:47	Modified:	12 Jun 2007 8:28
Reporter:	Tom Ammon	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S3 (Non-critical)
Version:	5.0.24	OS:	Linux (RedHat Enterprise Linux AS4)
Assigned to:		CPU Architecture:	Any

Description:
When the MySQL 5.0 rpm for RHEL4 is used to upgrade from the stock (4.1) version of MySQL that comes with RHEL4, some things aren't happening in the installation that should. Namely:
-the mysql user and group are not created
-appropriate permissions are not assigned to /var/lib/mysql

The problem doesn't make itself manifest until _after_ the mysql service is shut down. After the daemon is shut down, it fails to start again until after the above steps are taken.

How to repeat:
To recreate the problem, from a clean install of RHEL4 (including MySQL 4.1), upgrade MySQL to 5.0 using rpm -Uvh. In my environment, I installed MySQL-server-standard, MySQL-client-standard, and MySQL-shared-compat. The service will start successfully. Shut down the daemon and try to start
it up again. It will try for a while, and finally fail.

Suggested fix:
To fix the problem, run the following at the shell immediately after installation:

shell> adduser mysql
shell> chown -R mysql.mysql /var/lib/mysql

Now the daemon starts just fine. These seem like they are tasks that should be taken care of by the rpm.

Thank you for a problem report. Please, specify the exact RPM used (or give URL to download). Version should be 5.0.x, not simply 5.0.

The RPM I used is:

MySQL-server-standard-5.0.24-0.rhel4.i386.rpm

1) I checked the "spec" file:
In the "%post" section, it contains a line to add a user, 
but intentionally ignores any errors:

useradd -M -r -d $mysql_datadir -s /bin/bash -c "MySQL server" -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true

On uninstall, the user is intentionally *not* removed, so he should still exist from the previously installed 4.1.

2) I checked our RedHat 4 machine:

$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
$ find /usr/bin /usr/sbin -name '*user*' -print | xargs ls -ld
...
lrwxrwxrwx  1 root root       7 Nov 24  2005 /usr/sbin/adduser -> useradd
...
-rwxr-x---  1 root root  128312 Nov 17  2005 /usr/sbin/useradd
...

So I have no idea (yet) why it failed for the reporter.

Question:
Does that symlink between "useradd" and "adduser" exist, so that the spec file call to "useradd" and his suggested "adduser" lead to the same binary ?

As you can see from Joerg's comment, we do have a command to add user. Can you try to repeat the same set of steps (install 4.1.x, upgrade to 5.0.x) but with checking of /etc/passwd, /etc/group and file prefissions (with numeric uid and gid) for the /var/lib/mysql directory?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Sorry, I meant file permissions (not "file prefissions") in my previous question. It was a weird typo.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Please, try to repeat with RPMs of a newer version, 5.0.27, and inform about the results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I had the same problem.  The mysql rpms uninstall the earlier version and
remove the mysql user.  The new RPMs (listed below) do not add a mysql user back.
The original mysql id number was 27.  When I manually add user to add the
mysql user back, it is 501.  The stuff in /var/lib/mysql is still owned by 27.

I notice that the original mysql init (in this case is actually mysqld) also
does a chown -R mysqy:mysql on /var/lib/mysql when it starts.  The new init
  (just mysql) does not.  (Both are in /etc/init.d), so even when you add
the mysql user back, the permissions aren't right until you do another chown.

To summarize:

  5.0.19 installation removes the mysql user and does not add it back (at least   
  for me)

  manually adding the mysql user creates a different ID number (501 instead of
  27) so /var/lib/mysql  is still owned by 27

I made a thing to fix it.  After running the mysql RPMs my script

 - checks for a mysql user.  If one does not exist then it adds one.
 - adds a chown line to /etc/init.d/mysql under the 'start' portion
 - comments out the basedir= in /etc/my.cnf (suggested elsewhere).

why is the previous mysql in /etc/init.d/mysqld and the new one in 
/etc/init.d/mysql ?

Anyway here are the RPMs I used.  I suspect the server is the important one.

  mysql++-2.2.3-1.el4.i386.rpm
  MySQL-client-standard-5.0.19-0.rhel4.i386.rpm
  MySQL-devel-standard-5.0.19-0.rhel4.i386.rpm
  MySQL-server-standard-5.0.19-0.rhel4.i386.rpm
  MySQL-shared-compat-5.0.19-0.rhel4.i386.rpm
  MySQL-shared-standard-5.0.19-0.rhel4.i386.rpm

and centos 4.4 2.6.9-42.0.10.ELsmp #1 SMP

Please, try to repeat with a newer version, 5.0.41, and inform about the results. Both 5.0.24 and 5.0.19 are really old.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".