http://qa.mandrakesoft.com/show_bug.cgi?id=1404
------- Additional Comments From [EMAIL PROTECTED] 2003-03-05 23:18 -------
The 3.23 tables are not updated and stopping MySQL fails somehow:
$ urpmi MySQL-Max
installing /var/cache/urpmi/rpms/MySQL-Max-4.0.11a-2mdk.i586.rpm
Preparing... ##################################################
1:MySQL-Max ##################################################
cat: /var/lib/mysql/mysql.pid: No such file or directory
AFAICS, the error is from the following line in the postin script's failing:
kill `cat $pid_file` &> /dev/null
Afterwards, the pid file is still lying around and manually executing the line
indeed kills the MySQL daemon. So I guess it is some race condition.
The disturbing result is that MySQL is still running with --skip-grant-tables
and "service mysql stop" will fail to stop the service (because the
/etc/init.d/mysql script is looking for a pid file with the hostname encoded).
---------
Ah, after some trial and error I found the culprit: detaching mysqld returns too
early. mysql_fix_privilege_tables cannot open the connection and the cat
$pid_file fails because there is no pid_file yet. A sleep would probably help.
A cleaner solution would be to have a "waitfor" command (seen on QNX) that
blocks until a file/socket exists. Could be easily emulated by a loop:
waitfor()
{
while [ ! -e $1 ]; do
usleep 100000
done
}
Not sure, if a timeout is needed for the case at hand, i.e. whether mysqld could
fail after detaching. Probably yes.
Another thing is that hard-coding /var/lib/mysql in postin is not that pretty.
my_print_defaults is made for this purpose. How about something like:
datadir=`my_print_defaults mysqld | grep '^--datadir' | cut -d= -f2-`
cd $datadir
pid_file=$datadir/mysql.pid
I am aware that grep isn't in the core-utils and therefore potentially
problematic, but you get the idea.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
------- Reminder: -------
assigned_to: [EMAIL PROTECTED]
status: ASSIGNED
creation_date:
description:
See the mentioned URL. There are some steps to be taken in order to upgrade from
3.23 to 4.0 (4.0 will work on a 3.23 database without those, but not all
features are available). The most notable is the one give in the Summary. Of
course, it is arguable, if all those steps should be automatic, and I would
surely be fine with only printing a message that the user has to run the steps
(maybe cite the mentioned URL).
But I think if neither is done, there will be a lot of questions coming back why
certain features of 4.0 do not work after upgrading.
