Actually the SIGKILL is really always a no go unless a sysadmin decides to do this manually. An upstart script should never do this automatically (not even as a feature ;-) ) I can guarantee that in more than 90% of the cases after a SIGKILL you will have corrupted tables. With the default config of auto recover myisam tables and smaller sites having small databases, this is not such an issue (altough eventually you will have dataloss), but in larger setups with tables containing millions of records this is really a nightmare. In large scale setups where transactions are not necessary, it doesn't make sense to use INNODB instead and indeed, with innodb you would have the exact same issue.
Ideally, the upstart mechanism should have support for "kill timeout 0" meaning a KILL will never be send for that specific job. If the user still wants to kill, ideally he should be able to do "stop --force mysql". Since upstart does not support this mechanism, I suggest to indeed add "kill timeout 900". With the init.d system the mysql stop was handled a lot better. It simply sent the TERM signal and waited for 20 seconds. If after 20 seconds MySQL was still running, the stop returned with an error saying so and an exit code != 0 -- MySQL upstart stop job does not cleanly shutdown mysql https://bugs.launchpad.net/bugs/620441 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mysql-dfsg-5.1 in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
