MySQL Bugs: #14457: /etc/init.d/mysql script doesn't work under fedora core 4

Bug #14457	/etc/init.d/mysql script doesn't work under fedora core 4
Submitted:	29 Oct 2005 6:29	Modified:	14 Dec 2005 11:06
Reporter:	Walery Studennikov	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S2 (Serious)
Version:	5.0.15	OS:	Linux (Linux (Fedora Core 4))
Assigned to:		CPU Architecture:	Any

Description:
I'm using MySQL-server-5.0.15-0.glibc23.i386.rpm under Linux (Fedora Core 4 distro).
There are at least 3 problems in this RPM packet:

1. User "mysql" is not created when making rpm update (rpm -U), so mysql server will fail to start without this user

2. Path to my mysqld_safe detected wrong at /etc/init.d/mysql script.
It tries to run /var/lib/bin/mysqld_safe instead of /usr/bin/mysqld_safe

3. "/etc/init.d/mysql start" command failed anyway, even when fixing previous two problems.
----------
# /etc/init.d/mysql.was start
Starting MySQL...................................          [ FAILED ]
----------
So, mysql server was not started 

How to repeat:
Install MySQL-server-5.0.15-0.glibc23.i386.rpm under Fedora Core 4.
run /etc/init.d/mysql start 

Suggested fix:
1. Fix RPM install/update scripts
2. Fix /etc/init.d/mysql script

Do you have SELinux installed ?. If yes, please see:

http://bugs.mysql.com/bug.php?id=12676

Thanks in advance.

> [29 Oct 23:26] Miguel Solorzano
> Do you have SELinux installed ?. If yes, please see:
> http://bugs.mysql.com/bug.php?id=12676

No, I'm not using SELunux.

Did you do an update with an installed instance before?
Check if "/var/lib/mysql" belongs to the user "mysql".

> [31 Oct 10:39] Thomas Hartwig
> Did you do an update with an installed instance before?

I've installed the package using update procedure (rpm -U).
The previous installed version was MySQL 4.1 (from FC4 distro).

> Check if "/var/lib/mysql" belongs to the user "mysql".

Yes, I'lve fixed this by hands.
But /etc/init.d/mysql script doesn't work anyway.
See p.3 in the original bure report message.

I've tried to repeat the behaviour you described on Fedora Core 1:

1. I had removed all the references to mysql from users database:

[root@Fedora tmp]# cat /etc/passwd /etc/shadow /etc/group | grep mysql

2. I had downloaded and installed the same RPM as yours:

[root@Fedora tmp]# rpm -U MySQL-server-5.0.15-0.glibc23.i386.rpm
...
The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at https://order.mysql.com
Starting MySQL. SUCCESS!
[root@Fedora tmp]# cat /etc/passwd | grep mysql
mysql:x:100:101:MySQL server:/var/lib/mysql:/bin/bash

So, user is created.

Then, why do you think mysqld_safe is called from the wrong directory? How it happens? And, finally:

[root@Fedora tmp]# /etc/init.d/mysql start
Starting MySQL SUCCESS!

Everything works as expected. Now, I understand that FC4 is NOT the same as FC, but I do not understand how it can happen that the same generic RPM works differently on different FC versions...

Do I really need to test it on FC4?

Valeriy Kravchuk wrote:
> Then, why do you think mysqld_safe is called from the wrong directory?
> How it happens?

I've inserted debug messages into /etc/init.d/mysql to show the
full path to mysqld_safe just befure trying to run it.
It is /var/lib/bin/mysqld_safe.
So, some logic inside /etc/init.d/mysql seems to be wrong.

> Everything works as expected. Now, I understand that FC4 is NOT the same as FC,
> but I do not understand how it can happen that the same generic RPM works
> differently on different FC versions...
> Do I really need to test it on FC4?

Yes, please.
Also, plese, try to make rpm update (from previous mysql version), not just rpm install.

my system is
Linux localhost.localdomain 2.6.13-1.1532_FC4 #1 Thu Oct 20 01:30:08 EDT 2005 i686 i686 i386 GNU/Linux

when i install MySQL-server-5.0.15-0.i386.rpm
i got a problem like this

Preparing...                ########################################### [100%]
   1:MySQL-server           ########################################### [100%]
051101 17:23:39 [Warning] Asked for 196608 thread stack, but got 126976
051101 17:23:39 [Warning] Asked for 196608 thread stack, but got 126976
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h localhost.localdomain password 'new-password'
See the manual for more instructions.

NOTE:  If you are upgrading from a MySQL <= 3.22.10 you should run
the /usr/bin/mysql_fix_privilege_tables. Otherwise you will not be
able to use the new GRANT command!

Please report any problems with the /usr/bin/mysqlbug script!

The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at https://order.mysql.com
Starting MySQL...................................[FAILED]

I had the same problem, but on Mandriva with the following rpms
libmysql15-5.0.15-4mdk
MySQL-client-5.0.15-4mdk
MySQL-5.0.15-4mdk
perl-DBD-mysql-3.0002-2mdk
libmysql14-4.1.12-3mdk
MySQL-common-5.0.15-4mdk

 I just changed my.cnf:

default-mysqld-path=/usr/sbin/mysqld-std

it pointed to a non-existing /usr/sbin/mysqld

have fun,

Tools

Walery:

Please, send the content of your my.cnf file. Have you tried to perform a fresh installation on FC4 (not upgrade)?

Valeriy Kravchuk wrote:
> Please, send the content of your my.cnf file.

----------
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=cp1251
ft_min_word_len=2

[mysql]
default-character-set=cp1251
#init-connect="SET NAMES cp1251"
     
[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
----------

> Have you tried to perform
> a fresh installation on FC4 (not upgrade)?

No, I haven't tried.

I had no root access neither to FC4, nor to Mandriva right now. So, I'd better change status to open until I'll get any one of them installed.

I had same problem on Red Hat Linux Enterprise 3... until i commented out basedir in my.cnf i could not start it using mysql.server script ..... even though basedir was correct and displays i addd to mysql.server showed that it should have found everything but did not....

i did a rpm -U MySQL-server-standard-5.0.15-0.rhel3.i386.rpm .... discovered that after upgrade i could manually start mysqld but i could not use script.... further investigation revealed that it was not looking in correct directories when it went to find either mysqlmanager or mysqld... commenting out all directory options in my.cnf and telling to use mysqlmanager was the only solution i found that worked..

everyting is installed in standard places.. upgraded from 4.1.12

still trying to figure out why i don't have INNODB support after upgrade.. not sure about that one yet (have question on forums)...

> [10 Nov 16:23] Valeriy Kravchuk
> I had no root access neither to FC4, nor to Mandriva right now. So, I'd
> better change status to open until I'll get any one of them installed.

I think the problem is not only at FC4 / Mandriva.
Ite seems that the problem is with "basedir" option at my.cnf config.

I've just repeat the installation of MySQL-server-5.0.15-0.glibc23.i386.rpm on a fresh Fedora Core 1 (with mysql user, group and any server rpms removed), WITHOUT /etc/my.cnf. It installs and starts without any problems. So, the problems you described are either related to other Linux distributions (several of them), or to the content of /etc/my.cnf you had BEFORE installing 5.0.15. 

rpm -U for this .rpm do not create any /etc/my.cnf, it do create mysql user and group, and the default value for basedir just works.

> So, the problems you described
> are either related to other Linux distributions (several of them), or to
> the content of /etc/my.cnf you had BEFORE installing 5.0.15.

Yes, exactly.
The problem is that mysql INCORRECTLY handles "basedir" option of my.cnf config.
But it should.

Why do you think that MySQL _handles_ basedir incorrectly? It does it in the following way (quote from the beginning of the /etc/init.d/mysql script):

if test -z "$basedir"
then
  basedir=/
  bindir=/usr/bin
  datadir=/var/lib/mysql
  sbindir=/usr/sbin
  libexecdir=/usr/sbin
else
  bindir="$basedir/bin"
  datadir="$basedir/data"
  sbindir="$basedir/sbin"
  libexecdir="$basedir/libexec"
fi

It exactly follows my _personal_ expectations: basedir is a kind of a root directory for the MySQL tree, it should have ./bin subdirectory with binaries normally used (see bindir setting for the nondefault basedir). What you had in your my.cnf was basedir=/var/lib - it is totally inappropriate place for MySQL base directory (/var it is proper place for data directrory, indeed, but not for any executables). 

So, why not to set datadir in my.cnf and not to leave the default value for the basedir? Why not to take into account the way it works, simply (even if it worked differently before)?

In 4.1.x basedir was basedir /usr/local/mysql by default (also reasonable and expectable place), but not /var/lib. Those basedir=/var/lib setting are simply non-default (and incorrect, IMHO). So, if you had mysql in unusual location, just be ready to change something after the default installation. I see no bugs here.

I'm having the same problem. I installed the Fedora Core 4, without MySQL. Installed the Mysql-server-glibc23 version 5 RPM, with -i option. Before he asked Mysql-shared and perl-dbi . Changed the datadir to /home/mysql, created the /etc/my.cnf file with the datadir=/home/mysql line. With command mysqld_safe start & the server starts normally, but with the mysql script it gets FAILED. Is there any bug in this script ?

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 same problem on FC2 and FC3 until i commented out
basedir in my.cnf as recommended above. After that, the startup script worked.

The same happens on FC4 while installing MySQL 5.x from the generic RPMs dynamically linked against glibc.

I think that since it's been almost 8 months this would already get fixed, huh? :)

"Meine meinung nach" the problem lies in the fact that the 

bindir and the sbindir are supposed to be under $basedir.

Why is it like this ?
Probably to allow having multiple mysql versions on a single machine.

Well the RPM apparently thinks otherwise : it dumps everything in /usr/bin and /usr/sbin

This is why removing basedir from my.cnf works : it prevents the script from assuming the binaries are under the installation dir.

If you have a simple production server you can probably go that way. If instead you're managing several projects with various requirements your best bet is to stay in a side-by-side mindset and move the binaries where they are expected.  More difficult though.