Hello James, 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.2 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! ** Changed in: lsb (Ubuntu Trusty) Status: In Progress => Fix Committed ** Tags added: verification-needed -- 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/1582813 Title: service --status-all always reports upstart managed daemons as running Status in lsb package in Ubuntu: Fix Committed Status in lsb source package in Trusty: Fix Committed Bug description: [SRU Justification] SRU regression. The change to lsb-base that landed into -updates on the 12th of May: 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 <joshua.zh...@canonical.com> Thu, 06 Aug 2015 11:11:16 -0500 changed the behaviour of init.d scripts to pass through to the associated upstart configuration for process management, where packages ship both an upstart configuration and an init.d configuration. This has a rather nasty side effect on 'service --status-all', which calls the 'status' method on all installed init.d scripts - this gets translated into: status <service-name> for upstart scripts, which correctly identifies the process as not running, but always returns a 0 return code. As a result, --status-all incorrectly identifies upstart processes as running even when they are not. [Regression potential] Minimal. This SRU updates the behavior of the lsb init script upstart diversion to implement LSB-compliant return values for the 'status' subcommand. It is possible this behavior change will differ from the original behavior of some init scripts, but that behavior was undefined. [Test case] 1. On an installed trusty system, run this command to get a list of affected upstart jobs: for job in $(initctl list | awk '/stop\/waiting/ { print $1 }'); do if [ -x "/etc/init.d/$job" ]; then echo $job; done 2. Check the status of this service in the output of service --status-all: service --status-all 2>&1 | grep procps 3. Confirm that the service is shown as running, despite us knowing above that it is not: [ + ] procps 4. Install the lsb-base package from trusty-proposed. 5. Check the status of this service again in the output of service --status-all: service --status-all 2>&1 | grep procps 6. Confirm that the service is no longer shown as running: [ - ] procps To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1582813/+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
