Shutdown timeout values are inconsistent between init.d, upstart and systemd init scripts

[Mark Stosberg]

In `/etc/init/mysql.conf`, the configuration is set to wait 5 minutes after a SIGTERM is issued before a SIGKILL is issued. The value was intentionally set that high because sometimes the default of 5 seconds wasn't long enough [1].

 1. https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/620441

The code used for this in the upstart script is:

   kill timeout 300

However the parallel change was not made to /etc/init.d/mysql
It has the same logic, but waits only 10 seconds, like this:

```
            killall -15 mysqld
            server_down=
            for i in 1 2 3 4 5 6 7 8 9 10; do
              sleep 1
              if mysqld_status check_dead nowarn; then server_down=1; break; fi
            done
          if test -z "$server_down"; then killall -9 mysqld; fi
```

I would consider submitting a patch to change the timeout from 10 seconds to 300 in this script, but I can't believe spelling out the numbers from 1 to 300 is the best way to do that, as the current code counts to 10 like this.

I know that using upstart and the "service" command are the preferred way to manage MySQL, but as long as the init.d script continues to be shipped it should parallel the upstart script when possible.

This change matters to projects like ec2-consistent-shutdown, which tries to shutdown MySQL cleanly across a number of linux variations. It currently does that with a hardcoded reference to /etc/init.d/mysql, which apparenty works, while I don't think the upstart syntax would be as portable. [2]

 2. https://github.com/alestic/ec2-consistent-snapshot/pull/68

[Mark Stosberg (markstos)]

I looked at the mysql-5.6 package in the xenial distribution.

It provides 3 init scripts: one for upstart, one for SysV init, and one
presumably for systemd. Each provides a different value for the server
to shutdown: 10 seconds, 300 seconds or 600 seconds, depending on which
service you use.

I did see a better syntax for waiting 30 seconds using Bash, though.

Before:

> for i in 1 2 3 4 5 6 7 8 9 10; do
> sleep 1

After:

> for i in $(seq 1 300); do
> sleep 1

That's my recommended patch to /etc/init.d/mysql

I also recommend fixing the mysql-server 5.6 package to be consistent
between the 3 init scripts.

    Mark

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

For 5.5:

We have dropped mysql-5.5 since Trusty, so the only fixes now need to have real user impact and minimal regression risk. You said "I know that using upstart and the "service" command are the preferred way to manage MySQL, but as long as the init.d script continues to be shipped it should parallel the upstart script when possible." but please see bug 1273462: under no circumstances should the code in the init.d script actually run on an upstart system. So there is no need to fix the init.d script in Trusty or earlier.

For 5.6, it would be useful to bring behaviour in sync and so I appreciate you pointing it out. I'll add a task for 5.6 to track this.

[Robie Basak (racb)]

I'm going to mark this as Invalid for 5.5, not because your report is invalid but because the package no longer exists for Xenial and there is no valid fix required for Trusty.

[Mark Stosberg (markstos)]

Thanks for the reply.

For the mysql-5.6 package, I recommend clearly out the "init.d" script
except for the redirect to the "upstart" script.

This will avoid the false impression that the code in in the "init.d"
script is still active.

       Mark

[Robie Basak (racb)]

We derive the package from Debian, and in Debian multiple init systems are supported. So the package does need to ship all three. In Debian the user could switch between init systems and reboot, and the package and associated service should continue to work.

I appreciate that this could be confusing in that you might thing that an init.d script is active when in fact the system is running upstart (or systemd) and so not using it, but that is how the packaging currently works. If that should be changed, it needs to be addressed as part of a larger effort - there is nothing we can do specifically in MySQL packaging to make it less confusing.

[Robie Basak (racb)]

> in that you might thing

think