If i stop mysql by running /etc/init.d/mysql stop, and immedeatelly start it with /etc/init.d/mysql, before all the mysql processes have existed, mysql will not start on this machine till the next reboot. this doesn't seem related to mysql, but to the init script - it doesn't wait until mysql exits. stopping mysql, waiting till all processes exist, and then starting it works around the problem. Reproducible: Always Steps to Reproduce: 1./etc/init.d/mysql stop;/etc/init.d/mysql start Actual Results: mysql did not start. Expected Results: stopped and started mysql the machine is sparc e450, not that i think it's related
make sure you are using the latest mysql ebuild, as I cannot reproduce this on x86 hardware at all.
using latest ebuild : emerald root # epm -qi mysql Name : mysql Version : 4.0.13 Release : 3 Slot: 0 Install date: Sun Jun 22 20:25:32 2003 Build Host: sparc-unknown-linux-gnu Group : dev-db License: GPL-2 Size : TBD Packager : robbat2 URL : http://www.mysql.com/ Now, the same condition occurs if mysql dies (i can simulate this my "kill -9 (pid of safe-mysqld), and killall mysqld) - after this you cannot start mysql again still without reboot. I could provide root access to the machine for debugging perposes of this problem - contact me directly by email.
Please upgrade all the way to 4.0.14-r1 (In ~sparc and ~x86 presently). following your instructions as: killall -9 safe_mysqld killall mysqld then doing: /etc/init.d/mysql zap /etc/init.d/mysql start it starts fine on 4.0.14-r1 for me.
Ok, now i get it. that i was missing was the zap option - after running it i can start the service. but on my machine /etc/init.d/mysql stop doesn't wait for mysql to shutdown, so when i run /etc/init.d/mysql start, it thinks that mysql is started successfully (when it actually haven't shutdown yet), instead of detecting that mysql is already running. this seems to me like some better detection on the start stop process are in order, unless one should be expected to run the zap command between service restarts. gentoo rc scripts can be confusing for a newcomer.
Ah, I think I know the problem... how many processors in your sparc ? doing this command: "/etc/init.d/mysql stop ; /etc/init.d/mysql start" runs both of them simultaneosly and lack of locking causes a few problems here...
I actually have 2 processors on that machine ;)
azarah: it seems that start-stop-daemon doesn't have any locking against concurrent calls to it, as in Alex's case here where there are two instances of it running simultaously from what I can see. Perhaps it should have some locking to prevent this? If you agree, I'll try to put together a patch for it.
`/etc/init.d/mysql stop` doesn't stop mysql. (mysql-4.0.13-r3 on PPC) Checking /usr/bin/mysql_safe (the --exec value passed to the start-stop-daemon) reveals that signals '', 1, 2, 3, and 15 are caught to prevent mysql from being kill'ed. Shouldn't this behavior be configurable through the use of a configuration script? e.g., /etc/conf.d/mysql How is one supposed to stop mysqld? Shouldn't `/etc/init.d/msyql stop` accomplish this?
Is this fixed in the recent mysql builds? I am not able to reproduce with /etc/init.d/mysql stop;/etc/init.d/mysql start it works as would be expected, on a quad ultrasparc box.
afaik this got fixed upstream for 4.0.16 or .17, so closing this bug.
