Bug 609734 - Make mysqld startup/shutdown timeouts settable from outside the init script
Make mysqld startup/shutdown timeouts settable from outside the init script
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql (Show other bugs)
5.5
All Linux
low Severity low
: rc
: ---
Assigned To: Tom Lane
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-30 19:12 EDT by Robin Bowes
Modified: 2013-03-20 05:45 EDT (History)
3 users (show)

See Also:
Fixed In Version: mysql-5.0.95-2.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-20 05:45:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Bowes 2010-06-30 19:12:40 EDT
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?
Comment 1 Robin Bowes 2010-06-30 19:14:34 EDT
BTW, I couldn't find a mysql-server component against which to raise this ticket - what component should one use for mysql server issues?
Comment 2 Robin Bowes 2010-06-30 19:40:58 EDT
I should also point out that I'm running the suggested mods in production.
Comment 3 Tom Lane 2010-06-30 23:09:56 EDT
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?
Comment 4 Robin Bowes 2010-07-01 04:36:18 EDT
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.
Comment 5 Tom Lane 2010-07-02 13:35:23 EDT
> ... 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.
Comment 6 Tom Lane 2010-07-15 10:50:57 EDT
FYI, I've modified the init script for this in Fedora 13 and up.  So eventually it should propagate back to RHEL5.
Comment 7 Robin Bowes 2010-07-16 07:03:26 EDT
Tom,

Where can I see the revised script?

R.

PS. No, I don't have any concrete suggestions for improvement!
Comment 9 Robin Bowes 2010-07-16 11:04:27 EDT
Thanks.

Any reason you use [ -e /etc/sysconfig/$prog ] rather than -r or -f ?

R.
Comment 10 Tom Lane 2010-07-16 12:14:14 EDT
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.
Comment 11 Robin Bowes 2010-07-16 12:48:55 EDT
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.
Comment 12 Tom Lane 2010-07-16 13:26:47 EDT
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.
Comment 13 Robin Bowes 2010-07-16 13:42:17 EDT
No, I'm not particularly either. Just curious as to why it is what is.

Hey ho!
Comment 14 Honza Horak 2013-03-20 05:45:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.