MySQL Bugs: #56581: RPM scripts use hardcoded datadir location

Bug #56581	RPM scripts use hardcoded datadir location
Submitted:	6 Sep 2010 8:38	Modified:	2 Mar 2011 3:35
Reporter:	Axel Schwenke	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S3 (Non-critical)
Version:	5.1.49	OS:	Linux
Assigned to:	Joerg Bruehe	CPU Architecture:	Any

Description:
The PREIN and POSTIN RPM scripts now check if a server is already running and only then start the server after an upgrade (fix for bug #27072).

This functionality is broken because it relies on the MySQL datadir being /var/lib/mysql - this string is hardcoded in the scripts.

How to repeat:
Configure MySQL to use a datadir that is not /var/lib/mysql. Then run an RPM upgrade with the MySQL server running. The server should be restarted after the upgrade, but isn't.

Suggested fix:
The RPM scripts should try harder to find out if a server is running. At least /etc/my.cnf should be checked for the real datadir. I.e. one could use my_print_defaults for that.

Looking at the issue ...

Verified as described (to be expected).

I discussed the matter with the reporter:
The fix should be to give the values for "datadir" and "pid-file" which are provided by "my_print_defaults", if any, precedence over the defaults.

Working on this.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/130338

3575 Joerg Bruehe	2011-02-03
      Fix  Bug #56581  	RPM scripts use hardcoded datadir location
      
      When fixing the 27072 bug, the shell snippets running before/after
      a RPM upgrade got expanded to look at files in the data directory
      and at the PID file.
      In this expansion, the standard locations were used.
      
      There are users who configure their installations to use non-standard
      locations for the data directory, the PID file, and other objects.
      For these users, the fix of 27072 did not work.
      As a result, the fact that a server was running at upgrade start was
      not noticed, and the new server was not started after the upgrade.
      
      With this patch, the shell snippets now try to get these locations
      from "my_print_defaults" before falling back to the defaults.
      Now, the fact that the old server is running is again noticed (even
      with non-standard locations), and the new server is started.
      
      Also, the upgrade log is written to the correct data directory.
     @ support-files/mysql.spec.sh
        See the global comment for the purpose of this change.
        
        In tests on SuSE 11, it was found necessary to use the full path name
        of "my_print_defaults", it seems $PATH die not include "/usr/bin".

Looks like it might work.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/130866

3300 Joerg Bruehe	2011-02-09 [merge]
      Upmerge the fix for bug#56581 from 5.1 to 5.5.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/130867

3596 Joerg Bruehe	2011-02-09 [merge]
      Upmerge the fix for bug#56581 from 5.5 to trunk.

Pushed into mysql-trunk 5.6.2 (revid:joerg@mysql.com-20110209135143-hidhqdza13yd8aa0) (version source revid:joerg@mysql.com-20110209134708-rq7qhv8ibsaxe2gh) (merge vers: 5.6.2) (pib:24)

Pushed into mysql-5.1 5.1.56 (revid:joerg@mysql.com-20110209133727-n0pvmpynzl25pbdg) (version source revid:joerg@mysql.com-20110209133727-n0pvmpynzl25pbdg) (merge vers: 5.1.56) (pib:24)

Pushed into mysql-5.5 5.5.10 (revid:joerg@mysql.com-20110209134940-hjoi1i8cvglcgf56) (version source revid:joerg@mysql.com-20110209134322-byuhtoa0ttatvvap) (merge vers: 5.5.10) (pib:24)

Noted in 5.1.56, 5.5.10, 5.6.2 changelogs.

Some RPM installation scripts used a hardcoded value for the data
directory, which could result in a failed installation for users who
have a nonstandard data directory location. The same was true for
other configuration values such as the PID file name.

CHANGESET - http://lists.mysql.com/commits/130867