Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lsb (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Trusty |
Fix Released
|
High
|
Hua Zhang | ||
Utopic |
Fix Released
|
High
|
Unassigned | ||
upstart (Debian) |
Fix Released
|
Unknown
|
|||
upstart (Ubuntu) |
Fix Released
|
Critical
|
Dimitri John Ledkov | ||
Trusty |
Won't Fix
|
High
|
Dimitri John Ledkov | ||
Utopic |
Fix Released
|
Critical
|
Dimitri John Ledkov |
Bug Description
[ impact ]
Previously, init.d scripts that were replaced by upstart jobs had "upstart-job" symlink as a redirect in-place, which directed users at using upstart commands. Despite the good intentions, that never actually taught people about the correct interfaces. Now with the advent of co-installability of multiple init systems, users may have systemd, upstart, and sysv-init all installed on users system and have init.d scripts / upstart jobs / systemd units all available. To avoid any doubt, we should support executing /etc/init.d/ scripts which may call into upstart, or into systemd, or actually execute the script in question depending on whether there is native configuration for that particular job and which init system we are running under.
[ test case ]
Invoking init.d script should invoke upstart commands, for example:
$ /etc/init.d/ssh status
ssh start/running, process 4620
$ /etc/init.d/ssh stop
stop: Rejected send message, 1 matched rules; type="method_call", sender=":1.2469694" (uid=1000 pid=3908 comm="stop ssh ") interface=
$ sudo /etc/init.d/ssh stop
ssh stop/waiting
$ sudo /etc/init.d/ssh start
ssh start/running, process 5373
$ sudo /etc/init.d/ssh restart
ssh stop/waiting
ssh start/running, process 5405
Description: Ubuntu 13.10
Release: 13.10
mysql-server-5.5:
Installed: 5.5.35-
Candidate: 5.5.35-
Version table:
*** 5.5.35-
500 http://
500 http://
100 /var/lib/
5.
500 http://
In Ubuntu 13.10, the Upstart job and the init.d script do not work properly. In previous versions, the init.d script was a symlink to the wrapper script around upstart (/lib/init/
Also problematic is that if the upstart job is started using the service or start commands, the init.d script's "stop" function runs a mysql shutdown, but upstart simply restarts mysqld (because it's marked respawn in the upstart config).
Description: Ubuntu 14.04
Release: 14.04
mysql: mysql-server-
The problem in some setup was that the upgrade von 12.04 to 14.04 requres the adjustment of the InnoDB log size. Therefore the start of MySQL via upstart failed directly while the one via init started successfully and then failed as below.
<email address hidden>:~# status mysql
mysql start/running, process 5866
<email address hidden>:~# /etc/init.d/mysql stop
* Stopping MySQL database server mysqld [ OK ]
<email address hidden>:~# status mysql
mysql start/running, process 6101
<email address hidden>:~# /etc/init.d/mysql status
* /usr/bin/mysqladmin Ver 8.42 Distrib 5.5.43, for debian-linux-gnu on x86_64
Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Server version 5.5.43-
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/
Uptime: 7 sec
Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 15.428
<email address hidden>:~# stop mysql
mysql stop/waiting
<email address hidden>:~# /etc/init.d/mysql status
* MySQL is stopped.
This is horrible. The "status" commands report the wrong status and the start/stop commands do not work. If our operators are not super careful, our orchestration and monitoring system will go wild, report the wrong status and/or perform continuous restarts of the system as they think the service is not running. So we also fix it in trusty. the result will looks as below:
ubuntu@
mysql start/running, process 8523
ubuntu@
mysql start/running, process 8523
ubuntu@
mysql stop/waiting
ubuntu@
mysql stop/waiting
ubuntu@
mysql stop/waiting
[Regression Potential]
Some scripts call '/etc/init.
At the same time, '/etc/init.
Changed in mysql-5.5 (Ubuntu Trusty): | |
status: | New → Invalid |
Changed in upstart (Ubuntu Trusty): | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Dimitri John Ledkov (xnox) |
Changed in upstart (Ubuntu Utopic): | |
status: | Triaged → In Progress |
description: | updated |
Changed in upstart (Debian): | |
status: | Unknown → New |
description: | updated |
Changed in lsb (Ubuntu Trusty): | |
assignee: | Dimitri John Ledkov (xnox) → Hua Zhang (zhhuabj) |
status: | Confirmed → In Progress |
tags: | added: sts |
description: | updated |
no longer affects: | mysql-5.5 (Ubuntu) |
no longer affects: | mysql-5.5 (Ubuntu Trusty) |
no longer affects: | mysql-5.5 (Ubuntu Utopic) |
Changed in lsb (Ubuntu): | |
importance: | Undecided → High |
Changed in lsb (Ubuntu Utopic): | |
importance: | Undecided → High |
tags: | added: verification-done-trusty |
tags: |
added: trusty verification-done removed: scripts verification-done-trusty verification-needed |
Changed in upstart (Debian): | |
status: | New → Fix Released |
Thank you for taking the time to report this bug and helping to make Ubuntu better.
Confirmed. I expect /etc/init.d/mysql to continue to be a symlink to /lib/init/ upstart- job, but this does not appear to be the case. Instead, /etc/init.d/mysql is the init script from Debian packaging.
However, I don't see a symlink in /etc/rc2.d, so I believe that the upstart job is the only job used. Therefore, the issue occurs only if the /etc/init.d/mysql script is used manually. The "service" command appears to work correctly with upstart.
Workaround: don't use the /etc/init.d/ script directly.
Not affected: mysql-server-5.5 5.5.34- 0ubuntu0. 13.04.1 on Raring 0ubuntu0. 13.10.1 on Saucy
Affected: mysql-server-5.5 5.5.35-
Affected: mysql-server-5.5 5.5.35-0ubuntu1 on Trusty