[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
I sponsored this a while ago, unsubscribing sponsors. This is in the hands of the SRU team now. -- 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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"
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Hello Eric, or anyone else affected, Accepted lsb into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu6.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** 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 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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...
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Branch linked: lp:ubuntu/trusty-proposed/lsb -- 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: Fix Committed 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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 sta
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
I couldn't find any regression in my testing but since it wasn't that extensive, I'm not marking it a verified just yet. I really like the behavior improvement. Now, a regular user has a convenient way to check service statuses: /etc/init.d/acpid status Instead of the obtuse old way: env -u UPSTART_SESSION status acpid Note: "service acpid status" still operates on the session upstart. -- 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: Fix Committed 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime:
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** No longer affects: mysql-5.5 (Ubuntu) ** No longer affects: mysql-5.5 (Ubuntu Trusty) ** No longer affects: mysql-5.5 (Ubuntu Utopic) -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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,
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Changed in: lsb (Ubuntu) Importance: Undecided => High ** Changed in: lsb (Ubuntu Utopic) Importance: Undecided => High -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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 orch
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
With my SRU/TB hat on, I'd prefer making individual changes to e. g. mysql and other packages rather than changing this wholesale. Even if we did review all packages in Ubuntu which ship an init script that still leaves third-party scripts (and there are a lot of them). So I strongly recommend not to change the LSB package itself. -- 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime: 7 sec Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flu
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
> I think this should be the responsibility of existing packages to make they are doing the correct thing. That is not sufficient for an SRU. Your SRU needs to be compatible with the existing packages in the archive /as they are/, not as you declare they should be. However, per my previous comment, I don't think this is actually a problem. -- 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime: 7 sec Threads: 1 Questions: 108 Slow queries: 0 O
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
> Thus in trusty you don't have the option to use dependency-based > sysvinit scripts, you *have* to have rc?.d symlinks; and they are > being used through upstart too via /etc/init/rc.conf. In that case, any /etc/rc?.d symlink that shadows an upstart job is still going to be doing the wrong thing at boot by trying to start a service directly instead of via upstart. I don't think anything here is going to be a "regression". Only "changes in undefined and racy behavior". Yes, users may see some surprising changes in boot-time behavior as a result of this change; those will hopefully be changes for the better, but anything that relies on the current behavior of running both the init script and the upstart job at boot is deeply buggy and not supportable and should not block this SRU. -- 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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
I still disagree that it's "undefined behaviour" -- if we have used the actual init.d script so far to start e. g. mysql under upstart, then this does not sound either racy nor undefined; it surely isn't what we *intended* to do, though? My concern is, this fix will change behaviour for *all* packages shipping upstart jobs and sysvinit scripts, and it is not a given that the two do equivalent things. So if we now call /etc/init/frobnicator.conf instead of /etc/init.d/frobnicator and the former has a bug or a changed behaviour, that would be a regression? -- 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 versio
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
> No /etc/rc?.d/ links
Of course, but I thought the point here was that one could/would call
/etc/init.d/mysql directly when doing manual admin operations.
The first part of the patch, which disables an init.d script when called
through /etc/rc?.d/ is correct; if this happens (upstart job with rc?.d
symlink) this indeed is racy and undefined, but at the same time it
should happen very rarely. The description/test case should mention this
part, and fixing this in Trusty is prudent.
My objection is with manual admin operations via calling
/etc/init.d/foo; that seems to be the main focus of the patch -- the
second part beginning with UPSTART_JOB=${0#/etc/init.d/}. That's what
the description and test case talk about, and they don't talk about the
above race on boot.
We really don't know about all Ubuntu packages and even less about third
party packages. Calling "/etc/init.d/foo restart" may have worked for
people some packages, and it is neither racy nor undefined; the patch is
going to change that behaviour, and this is definitively not guaranteed
to be regression proof.
--
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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
@Martin Note that this is bug a regression - previously, before the (I presume) dh_installinit change, /etc/init.d/foo was a symlink to /lib/init /upstart-job so a user running /etc/init.d/foo by hand was redirected to upstart anyway. So while I appreciate that a user might now be getting desired behaviour by calling /etc/init.d/foo directly on some package somewhere, it seems unlikely that this change will regress by redirecting to the upstart job as we were doing for that package on a previous release - the window for that behaviour to have diverged is fairly small. -- 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.
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Changed in: upstart (Debian) Status: New => Fix Released -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released Status in upstart source package in Utopic: Fix Released Status in upstart package in Debian: Fix Released 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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 t
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
In Bug #1521771, I spent some time tracking down different behavior between the mysql-5.5 "init" and "upstart" scripts. They differ on how many seconds are waited between the SIGTERM and SIGKILL signals are sent. Different values can mean the difference between a slower clean shutdown and a shutdown interrupted by a SIGKILL signal. In the case of that of that package, redirecting the "init.d" calls to the upstart script will have a positive impact in my opinion-- giving more time for MySQL to shutdown cleanly. So the proposed patch will be functionally helpful. I do suggest that for any package that's affected by this, the "init.d" script should be cleaned out, so only the code remains that redirects people to the upstart script. There is nothing about this line of code in an "init.d" script which indicates that that all the code below it is about to ignored: . /lib/lsb/init-functions Nor does the proposed patch emit any output that confirms that redirect is happened. The result is that someone could pull their hair out wondering why the "init.d" script is not behaving as expected. Realize that there are packages like "ec2-consistent-snapshot" which exist only in a PPA and make a hardcoded call to "/etc/init.d/mysql". It does that in hopes of working on non-Debian-based systems as well. (The package is also several years old, from an era when init.d scripts were more common). I'm not sure what small projects are supposed to when they want to issue a command like "stop mysql" in a way that might work across SysV init scripts, upstart and systemd. -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released 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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Marking as verified on Trusty since I was able to do more testing. ** Tags added: verification-done-trusty -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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 monitori
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Tags removed: scripts verification-done-trusty verification-needed ** Tags added: trusty verification-done -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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 monito
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Hi Dimtri, Why it can be fixed for utopic but not trusty, they both still use upstart by default.. right ? -- 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: Confirmed 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 daubt, 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). 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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
@zhhuabj read my comment https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462/comments/6 I have correct the status and the location of where the fix needs to be backported to, without changing the effective status. In utopic the bug was fixed in upstart, but in trusty it needs to be fixed in lsb package as that's where the file to be patched should be at. Nobody did the work yet to cherrypick this fix into trusty, and it's open for anybody to be picked up. -- 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: Confirmed 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 daubt, 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). 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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Patch added: "trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+attachment/4428923/+files/trusty.debdiff -- 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: Confirmed 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 daubt, 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). 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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
@Edward, I tested above trusty.debdiff, but I found the constraint "Replaces: upstart (<< 1.12.1-0ubuntu8) && Breaks: upstart (<< 1.12.1-0ubuntu8)" prevents installing lsb-base package. error logs pls refer the link [1], so I remove them. I will upload trusty_v2.debdiff. Then I built a local deb binary lsb package and test, it looks good to me, the test result pls refer the link [2]. [1], https://pastebin.canonical.com/135504/ [2], https://pastebin.canonical.com/135505/ ** Patch added: "trusty_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462/+attachment/4430332/+files/trusty_v2.debdiff -- 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: Confirmed 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 daubt, 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). 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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** 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 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 version5.5.43-0ubuntu0.14.04.1-log + Protocol version 10 + ConnectionLocalhost 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] + + * None -- You received this bug notification because you are a member of Ubuntu Touch seeded pa
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Patch removed: "trusty_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462/+attachment/4430332/+files/trusty_v2.debdiff ** Patch removed: "trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462/+attachment/4428923/+files/trusty.debdiff ** Patch added: "trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462/+attachment/4431508/+files/trusty.debdiff -- 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: Confirmed 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 daubt, 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost via UNIX soc
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Changed in: lsb (Ubuntu Trusty) Assignee: Dimitri John Ledkov (xnox) => Hua Zhang (zhhuabj) ** Changed in: lsb (Ubuntu Trusty) Status: Confirmed => In Progress ** Tags added: sts -- 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 daubt, 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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 st
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Hi, any progress/update for this ? -- 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: Confirmed 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 daubt, 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). 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
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Hi Hua, Thanks for the patch, I can confirm that this patch fixed the issues I had with MySQL. -- 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 daubt, 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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
[Touch-packages] [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. - 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 version5.5.43-0ubuntu0.14.04.1-log - Protocol version 10 - ConnectionLocalhost 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. + 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.4
[Touch-packages] [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/4440530/+files/fix-lp1273462-trusty.debdiff -- 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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 mys
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
I'd like to see more thought in the Regression Potential section, because it clearly is NOT 'None'. Please search though and check if any existing packages call /etc/init.d/ either through any maintscripts, or if any other scripts will call /etc/init.d/. For each of these ensure that a 'No-op' is the correct response, otherwise you'll need to patch each of these packages to do the correct thing. For example 'freeradius' calls '/etc/init.d/freeradius reload' in its logrotate script, (bug 1406105) this would no-op that function (which maybe is better than what it does), but makes me think we need to very carefully check if any other packages do this kind of thing too. -- 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 Orac
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** 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 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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] - * None + * Some scripts call '/etc/init.d/ reload' will not work if + upstart script lacks a reload function and the reload func
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Chris, Could you review [Regression Potential] section I updated just now ? I think this should be the responsibility of existing packages to make they are doing the correct thing. This change in lsb should be in the right road, and the same change has also landed into Utopic, so this change should also land in Trusty. maybe what we can do now is try to enumerate this kinds of bad packages. right ? I also have some search for the call /etc/init.d/, but I did find at the moment except freeradius you mentioned in bug 1406105. Do you have any better way to deal with this tricky situation ? thanks. -- 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 trad
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
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 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. -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released Status in upstart source package in Utopic: Fix Released Status in upstart package in Debian: Fix Released 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 af
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
This bug was fixed in the package lsb - 4.1+Debian11ubuntu6.1 --- lsb (4.1+Debian11ubuntu6.1) trusty; urgency=medium * Add 01-upstart-lsb from the upstart package and make executing rc.d scripts no-op if there is an upstart job for that script. (LP: #1273462) -- Zhang Hua Thu, 06 Aug 2015 11:11:16 -0500 ** Changed in: lsb (Ubuntu Trusty) Status: Fix Committed => Fix Released -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Released Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released Status in upstart source package in Utopic: Fix Released Status in upstart package in Debian: Fix Released 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 version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost 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...@we
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
If a "stop" on the mysql init script does not work, the init script should be removed. -- 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: Confirmed 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 daubt, 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). 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
Re: [Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Steve Langasek [2015-09-01 21:38 -]: > 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 I suppose you are talking about insserv here. Note that trusty did *not* use that yet, it was enabled in utopic (https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-41ubuntu13) and it took a lot of fine-tuning and fixing to mop up the fallout. Thus in trusty you don't have the option to use dependency-based sysvinit scripts, you *have* to have rc?.d symlinks; and they are being used through upstart too via /etc/init/rc.conf. So this change does influence the boot significantly, and I'm not yet convinced that it necessarily regression proof? Or am I still missing something? -- 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
Re: [Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
On Wed, Sep 02, 2015 at 03:26:49PM -, Martin Pitt wrote: > I still disagree that it's "undefined behaviour" -- if we have used the > actual init.d script so far to start e. g. mysql under upstart, That is *not* what we're doing. Installing the mysql-server-5.5 package on trusty gives you: $ ls -l /etc/rc?.d/*mysql* /etc/init.d/*mysql* /etc/init/*mysql* ls: cannot access /etc/rc?.d/*mysql*: No such file or directory -rwxr-xr-x 1 root root 5491 Feb 19 2014 /etc/init.d/mysql -rw-r--r-- 1 root root 1770 Feb 19 2014 /etc/init/mysql.conf $ This is the behavior for all packages using a current version of debhelper to build. Any packages that ship an upstart job and *do* have symlinks in /etc/rc?.d for their matching init script are buggy and racy, and the change proposed here will not make this problem worse. -- 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
Re: [Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
On 3 December 2015 at 17:41, Mark Stosberg wrote: > In Bug #1521771, I spent some time tracking down different behavior > between the mysql-5.5 "init" and "upstart" scripts. They differ on how > many seconds are waited between the SIGTERM and SIGKILL signals are > sent. Different values can mean the difference between a slower clean > shutdown and a shutdown interrupted by a SIGKILL signal. > > In the case of that of that package, redirecting the "init.d" calls to > the upstart script will have a positive impact in my opinion-- giving > more time for MySQL to shutdown cleanly. So the proposed patch will be > functionally helpful. > > I do suggest that for any package that's affected by this, the "init.d" > script should be cleaned out, so only the code remains that redirects > people to the upstart script. > > There is nothing about this line of code in an "init.d" script which > indicates that that all the code below it is about to ignored: > > . /lib/lsb/init-functions > > Nor does the proposed patch emit any output that confirms that redirect > is happened. The result is that someone could pull their hair out > wondering why the "init.d" script is not behaving as expected. > > Realize that there are packages like "ec2-consistent-snapshot" which > exist only in a PPA and make a hardcoded call to "/etc/init.d/mysql". It > does that in hopes of working on non-Debian-based systems as well. (The > package is also several years old, from an era when init.d scripts were > more common). I'm not sure what small projects are supposed to when > they want to issue a command like "stop mysql" in a way that might work > across SysV init scripts, upstart and systemd. Across all distros and init systems the following works, and does the right thing, for the right init: service mysql stop -- Regards, Dimitri. -- 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 upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Fix Committed Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released 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
