Bug 609734 - Make mysqld startup/shutdown timeouts settable from outside the init script
Summary: Make mysqld startup/shutdown timeouts settable from outside the init script
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql
Version: 5.5
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-30 23:12 UTC by Robin Bowes
Modified: 2013-03-20 09:45 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-03-20 09:45:22 UTC


Attachments (Terms of Use)

Description Robin Bowes 2010-06-30 23:12:40 UTC
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 23:14:34 UTC
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 23:40:58 UTC
I should also point out that I'm running the suggested mods in production.

Comment 3 Tom Lane 2010-07-01 03:09:56 UTC
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 08:36:18 UTC
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 17:35:23 UTC
> ... 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 14:50:57 UTC
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 11:03:26 UTC
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 15:04:27 UTC
Thanks.

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

R.

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

Hey ho!

Comment 14 Honza Horak 2013-03-20 09:45:22 UTC
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.