[debian-mysql] Bug#430684: Bug#430684: Bug#430684: Calculating the timeout instead of, using a configuration setting.
monty at inaugust.com
Thu Jul 26 23:33:39 UTC 2007
Paul Veldema wrote:
>> - your suggestion isn't mutually exclusive from the previous one i
>> made. it could be made optional to specify a timeout value, and if
>> not specified, use the heuristic you provide, which would be the default.
> Monty's script does that, but gives a realy large default timeout
> instead, that makes me think, is there a case
> you would want a timeout at all? Until now I have only seen reasons to
> make the timeout larger.
I think it's the fuzzy "is it a desktop, is it a server" question. If
it's a desktop, you probably are ok with your desktop booting quicker
and mysql not quite being done before you start. If you are a server,
you probably do not want this behavior.
I think the original choice of 900 was based on the older, buggier
script which did not detect process failure and therefore would only
stop on failure once the timeout was reached. I think that could be
revisited now that the script is more robust.
> From Monty's script:
> # Default value, in seconds, afterwhich the script should timeout
> # for server start.
> # Value here is overriden by value in my.cnf.
> # 0 means don't wait at all
> # Negative numbers mean to wait indefinitely
> If using a timeout is only for specific cases, I would change the
> default to -1: wait indefinitely unless a
> specific timeout setting is given ('do not wait' or give a tight
> timeout). That would solve this issue for any future
> machine regardless of memory size or speed.
I agree. I'll see if I can convince them upstream, too.
> From monty:
>> PLEASE help me figure out ways to make it better.
> For ease of administration debian also starts a (initially generated but
> customizable and preserved during update) background script for table
> checks etc. For debian this should be included, because it is existing
> and desireable functionality. This would be a good option to add.
> I have made a version of Monty's script that includes all the above,
> without being Debian specific (see attachments). This version should
> seamlessly replace debian's version (/etc/init.d/mysql,
> and the generated /etc/mysql/debian-start). I tested this with the
> mysqlmachine-etch64 machine.
> The mysqlmaintenance.sh is made to contain the check/upgrade
> functionality as a separate script to keep the mysql.server.sh script
> clean and only for 'start|stop|status". It made for easy use in any
> custom startup script.
> A simple diff should show all differences with Monty's mysql.server.sh
> script. Any distro should be able to use the adjusted version without
> any extra startup setting.
Yes. I like it.
> To add a /etc/mysql/debian-start like default script for other distro's
> than debian, you can either adapt the mysqlmaintenance.sh script to
> include the defaults or add two settings to the my.cnf:
> # Custom Maintenance Script settings that runs at startup (debian
Ok. I haven't walked through it all yet, but on first glance it looks
good. <hat employee="mysql"> I'd love to check this in upstream, or at
least start checking it in to get some feedback. However, there's a good
amount of code here, and they won't let me unless you agree to our
community contribution agreement:
If you do, I'll start running this by the team as is for feedback. If
not, I'll try my best to do something similar without copying. Totally
your call, of course. </hat>
Looks like it'll just be going in to 5.1, regardless. Yay for dpatch!
>> (especially as currently it outputs extra linefeeds and dots that I
>> don't want it to on debian, I think)
> The output (when there are no faults) look good to me, no extra line
> feeds or dots the debian version
> of the start script does not have. Are there specific cases where the
> printing goes wrong?
Hmm. printing goes wrong on my old version for me in all cases... I'll
give this code a try and see if there is something silly going on.
More information about the pkg-mysql-maint