Florin,
You may put something like
# wait until mysql is ready
counter=0
while ! mysqladmin \
-h localhost -u user -pPassword ping >/dev/null 2>&1
do
counter=$((counter+1))
if [ $(($counter)) -gt $((200)) ]
then
echo "mysqld startup failed"
fi
done
into your startup script. But Gerald may be right that this delay is not
necessary for everyone. You don't have to do it for every service that
uses MySQL but only for the first one to use MySQL.
Thomas
On 21 Jun 2002, Florin Andrei wrote:
> On Fri, 2002-06-21 at 12:09, Gerald Clark wrote:
> > Or better yet,
> > add a sleep 2 to the beginning of the init.d program you are starting
> > that expects to connect to mysql.
> >
> > Why slow down the booting for everybody when some other daemon that
> > expects to connect to mysql
> > can not handle a failed connect properly?
>
> Because you have to do that for every service that uses MySQL (that
> means modifying lots of things) when, in fact, the problem is in MySQL's
> script (and it could be fixed modifying that one script).
>
> I don't quite understand why one would care so much about a couple of
> seconds of boot time? It's not like you reboot the production servers
> every day.
> And, BTW, we're talking about Unix, right? Not Windows RebootME. ;-)
>
> I would be much more concerned about the reliability of the boot-up
> process, than with some unrealistic "mine boots up one milisecond faster
> that yours".
> Reliability is _much_ more important than one second added to boot-up
> time. My customers wouldn't care too much if my servers came back one
> second later, but they would care very much if the servers came back
> without running some critical services.
>
> This is about playing by the rules too: when the init.d script returns,
> and it reports "OK" or success, or whatever, then it should tell the
> truth.
> Right now, mysql's init.d script is lying; it reports success, while
> MySQL didn't in fact finished the boot-up process. It is conceivable
> that it might actually fail later, because it still has a few things to
> do after the script already returned control (and happily reported
> success).
>
> This rule is observed by the init.d scripts of most of the other
> daemons. For example, Squid's script does not return control when
> shutting down the daemon until the daemon really closed all
> filedescriptors; on a very busy caching proxy, that might take one
> minute to complete (and i've seen even longer times occasionally)! But
> hey, one has to clean up its own mess, right?
> If you don't do that (wait for the proxy to properly terminate
> connections/flushing buffers), the init hierarchy would end up
> SIGKILLing squid at the end, with the risk of terminating active
> filedescriptors, etc.
> You only have to SIGKILL it if indeed it takes an exagerated time to
> shut down, and that means there's a problem hidden somewhere, and now
> you are aware of it and you can fix it.
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
