I think the change description within the patch is wrong (or at least, misleading/incomplete). What this patch actually does is: - for anything that calls /etc/init.d/foo, if /etc/init/foo.conf exists, make the call a passthrough to upstart instead of calling the init script. - for anything that calls /etc/rc?.d/[KS]??foo, make it a no-op.
The *only* thing that's made a no-op is the invocation of the init script *by the rc?.d symlink*. This is something that should never happen anyway; our dependency-based boot is already supposed to bypass invoking this script in favor of the upstart job. Any system that has been configured to not use the dependency-based boot in trusty is going to have race conditions at boot because of the combination of upstart job and init script, and while making this change may change the characteristics of the behavior at boot it would not be a regression because things are already broken. If anything interfaces with the /etc/init.d/foo script, that will still function, except that now it will *work* by passing through to the upstart job instead of trying to manipulate processes via (possibly non- existent) pid files etc -- 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. r...@webserver01.kurt..ref:~# status mysql mysql start/running, process 5866 r...@webserver01.kurt..ref:~# /etc/init.d/mysql stop * Stopping MySQL database server mysqld [ OK ] r...@webserver01.kurt..ref:~# status mysql mysql start/running, process 6101 r...@webserver01.kurt..ref:~# /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 r...@webserver01.kurt..ref:~# stop mysql mysql stop/waiting r...@webserver01.kurt..ref:~# /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] * Some scripts call '/etc/init.d/<service> reload' will not work if upstart script lacks a reload function and the reload function of /etc/init.d/<service> also uses PID. because it's managed by upstart now (the PID file does not exist). We should enumerate all those bad scripts and make them do the correct thing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
