touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #95053
[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Updated patch with bug number and version changed.
** Patch added: "fix-lp1273462-trusty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462/+attachment/4440531/+files/fix-lp1273462-trusty.debdiff
** Description changed:
[ 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
- daubt, we should support executing /etc/init.d/ scripts which may call
+ 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="com.ubuntu.Upstart0_6.Job" member="Stop" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
$ 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-0ubuntu0.13.10.1
Candidate: 5.5.35-0ubuntu0.13.10.1
Version table:
*** 5.5.35-0ubuntu0.13.10.1 0
500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu/ saucy-security/main amd64 Packages
100 /var/lib/dpkg/status
5.5.32-0ubuntu7 0
500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
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/upstart-job). This conflict
means that if the server was started using the init.d script, upstart
does not recognize that the server is running and will attempt to start
a second instance of mysqld.
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-5.5.43-0ubuntu0.14.04.1
- 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.
- root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
- mysql start/running, process 5866
- root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql stop
- * Stopping MySQL database server mysqld [ OK ]
- root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
- mysql start/running, process 6101
- root@xxxxxxxxxxxxxxxxxxxxx:~# /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-0ubuntu0.14.04.1-log
- Protocol version 10
- Connection Localhost via UNIX socket
- UNIX socket /var/run/mysqld/mysqld.sock
- Uptime: 7 sec
- Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 15.428
- root@xxxxxxxxxxxxxxxxxxxxx:~# stop mysql
- mysql stop/waiting
- root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql status
- * MySQL is stopped.
+ 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.
+ root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
+ mysql start/running, process 5866
+ root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql stop
+ * Stopping MySQL database server mysqld [ OK ]
+ root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
+ mysql start/running, process 6101
+ root@xxxxxxxxxxxxxxxxxxxxx:~# /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-0ubuntu0.14.04.1-log
+ Protocol version 10
+ Connection Localhost via UNIX socket
+ UNIX socket /var/run/mysqld/mysqld.sock
+ Uptime: 7 sec
+ Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 15.428
+ root@xxxxxxxxxxxxxxxxxxxxx:~# stop mysql
+ mysql stop/waiting
+ root@xxxxxxxxxxxxxxxxxxxxx:~# /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@maas:~/work/deb$ sudo start mysql
mysql start/running, process 8523
ubuntu@maas:~/work/deb$ sudo status mysql
mysql start/running, process 8523
ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql stop
mysql stop/waiting
ubuntu@maas:~/work/deb$ sudo status mysql
mysql stop/waiting
ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql status
mysql stop/waiting
-
[Regression Potential]
- * None
+ * None
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lsb in Ubuntu.
https://bugs.launchpad.net/bugs/1273462
Title:
Users can mistakenly run init.d scripts and cause problems if an
equivalent upstart job already exists
Status in lsb package in Ubuntu:
Fix Released
Status in mysql-5.5 package in Ubuntu:
Invalid
Status in upstart package in Ubuntu:
Fix Released
Status in lsb source package in Trusty:
In Progress
Status in mysql-5.5 source package in Trusty:
Invalid
Status in upstart source package in Trusty:
Won't Fix
Status in lsb source package in Utopic:
Fix Released
Status in mysql-5.5 source package in Utopic:
Invalid
Status in upstart source package in Utopic:
Fix Released
Status in upstart package in Debian:
New
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="com.ubuntu.Upstart0_6.Job" member="Stop" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
$ 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-0ubuntu0.13.10.1
Candidate: 5.5.35-0ubuntu0.13.10.1
Version table:
*** 5.5.35-0ubuntu0.13.10.1 0
500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu/ saucy-security/main amd64 Packages
100 /var/lib/dpkg/status
5.5.32-0ubuntu7 0
500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
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/upstart-job). This
conflict means that if the server was started using the init.d script,
upstart does not recognize that the server is running and will attempt
to start a second instance of mysqld.
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-5.5.43-0ubuntu0.14.04.1
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.
root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
mysql start/running, process 5866
root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql stop
* Stopping MySQL database server mysqld [ OK ]
root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
mysql start/running, process 6101
root@xxxxxxxxxxxxxxxxxxxxx:~# /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-0ubuntu0.14.04.1-log
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/mysqld/mysqld.sock
Uptime: 7 sec
Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 15.428
root@xxxxxxxxxxxxxxxxxxxxx:~# stop mysql
mysql stop/waiting
root@xxxxxxxxxxxxxxxxxxxxx:~# /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@maas:~/work/deb$ sudo start mysql
mysql start/running, process 8523
ubuntu@maas:~/work/deb$ sudo status mysql
mysql start/running, process 8523
ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql stop
mysql stop/waiting
ubuntu@maas:~/work/deb$ sudo status mysql
mysql stop/waiting
ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql status
mysql stop/waiting
[Regression Potential]
* None
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+subscriptions