In /etc/init.d/mysqld, there is code similar to this: STARTTIMEOUT=30 while [ $STARTTIMEOUT -gt 0 ]; do RESPONSE=`/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER ping 2>&1` && break echo "$RESPONSE" | grep -q "Access denied for user" && break sleep 1 let STARTTIMEOUT=${STARTTIMEOUT}-1 done and STOPTIMEOUT=60 while [ $STOPTIMEOUT -gt 0 ]; do /bin/kill -0 "$MYSQLPID" >/dev/null 2>&1 || break sleep 1 let STOPTIMEOUT=${STOPTIMEOUT}-1 done I'd like to be able to set the STARTTIMEOUT & STOPTIMEOUT values without modifying the script This would be possible if the values were set as follows: STARTTIMEOUT=${STARTTIMEOUT:-30} and STOPTIMEOUT=${STOPTIMEOUT:-60} It would also require an additional line at the top of the script to read any modified values from /etc/sysconfig/, something like: [ -f /etc/sysconfig/mysqld ] && . /etc/sysconfig/mysqld Any chance this small tweak can make it into a future release?
BTW, I couldn't find a mysql-server component against which to raise this ticket - what component should one use for mysql server issues?
I should also point out that I'm running the suggested mods in production.
Hm, see also bug #588090 and bug #565534. As noted in the latter, development head already has the /etc/sysconfig/mysqld call. I'm not entirely convinced that your idea is the cleanest fix for the former --- as noted there, it's not real clear what values users ought to select. Your idea is certainly easy though :-) What's your motivation exactly for wanting to change the values? Is a fixed value really good for what you're doing?
Hi, I needed to change the timeout values because many of the mysql servers I look after are very busy and simply take longer than 60 seconds to shut down. Now, I use puppet to manage my servers. To tweak a setting in my.cnf I simply make the change centrally on the puppetmaster server and it is deployed automatically to the clients. I have things configured so mysqld is restarted if the my.cnf changes. It is a pain if mysqld fails to restart simply because it times out when shutting down. So, in practise, setting the timeout value higher fixes the issue for me. But, I would suggest that the code used in the init script that checks for mysqld having started or stopped successfully is rather hacky and could be done better. R.
> ... hacky and could be done better. Yeah, likely ... I inherited that from the previous maintainer and won't try to defend it. Have you got any concrete suggestions for improvement? Note that the aspect of having a finite time limit can't go away.
FYI, I've modified the init script for this in Fedora 13 and up. So eventually it should propagate back to RHEL5.
Tom, Where can I see the revised script? R. PS. No, I don't have any concrete suggestions for improvement!
http://cvs.fedoraproject.org/viewvc/rpms/mysql/devel/
Thanks. Any reason you use [ -e /etc/sysconfig/$prog ] rather than -r or -f ? R.
Just paranoia ... it does need to be executable, so that is the correct test in detail. I believe this is the recommended coding according to the fedora packaging guidelines.
Huh? Did you typo there? What you said doesn't make any sense?! Anyway, looking here http://fedoraproject.org/wiki/Packaging:SysVInitScript it seems you're right. -e still seems strange though - testing if the file exists. What if it exists and is not readable? Or is a directory? Both unlikely, I know, but -e just seems wrong. R.
Er, you're right, I was momentarily confusing -e with -x. Nonetheless -e is the recommended test. It may be that they feel permissions checks are pointless for scripts that expect to run as superuser. Or maybe the recommendation could stand to be improved; but I'm not interested in taking up that battle myself.
No, I'm not particularly either. Just curious as to why it is what is. Hey ho!
I've realized, that the changes mentioned in comment #6 made it into RHEL-5 as a part of bug #703476. Despite it doesn't make the timeout values tunable, it could help in the mentioned cases. Anyway, it is now too late in the RHEL-5 release cycle to do more about this issue. RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2 [1] release of RHEL-5. Since phase 2 we'll be addressing only security and critical issues. Since I believe increasing the timeout should work well enough in the described case, I'm closing the bug as CURRENTRELEASE. In case you'll find out that it is still not fixed, please, open a bug against RHEL-6.