clash of upstart and sysvinit scripts

[Gertjan Oude Lohuis]

The mysql-server-5.6 installs two init-scripts: an upstart and a sysvinit one:

* /etc/init/mysql.conf
* /etc/init.d/mysql

Ubuntu uses upstart to manage the mysql-daemon, but this doesn't keep users from using /etc/init.d/mysql. This leads to confusing (and dangerous?) situation:

$ sudo status mysql
mysql start/running, process 1683

$ pgrep mysqld
1683

$ sudo /etc/init.d/mysql status
[..]
Server version 5.6.17-0ubuntu0.14.04.1
Uptime: 8 min 30 sec
[..]

$ sudo /etc/init.d/mysql stop
 * Stopping MySQL database server mysqld [fail]

$ sudo status mysql
mysql start/running, process 3853

So, stopping mysql with '/etc/init.d/mysql stop' actually did work, but upstart respawned the process like it should. This is very confusing.

Why does this package ship both init-scripts?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Laurent Declercq (l-declercq)]

To be more clear:

Both mysql-server-5.5 and mysql-server-5.6 packages (e.g. under Trusty Thar) provide a sysvinit script and an upstart job for mysql. The problem here is that the maintainer has a very strange approach:

1. The sysvinit script links are symply removed in the postinstall script using update-rc.d
2.The sysvinit script doesn't respects Debian policy section 9.11.1 which states that the sysvinit scripts should abort when an upstart job is provided (As I know, Ubuntu has choosen to follow Debian policy regarding cooexistence of upstart jobs and sysvinit scripts)

So yes, this situation can lead to several problems.

Anybody that run the mysql sysvinit script directly (/etc/init.d/mysql) instead of using service mysql <action> will have problems.

Also, if the upstart job is present, and if the sysvninit script is enabled (sysvinit script links created), the mysql socket will be missing on reboot.