touch-packages team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

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.
  root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
  mysql start/running, process 5866
  root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql stop
  * Stopping MySQL database server mysqld [ OK ]
  root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
  mysql start/running, process 6101
  root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql status
  * /usr/bin/mysqladmin Ver 8.42 Distrib 5.5.43, for debian-linux-gnu on x86_64
  Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
  Oracle is a registered trademark of Oracle Corporation and/or its
  affiliates. Other names may be trademarks of their respective
  owners.
  Server version	5.5.43-0ubuntu0.14.04.1-log
  Protocol version	10
  Connection	Localhost via UNIX socket
  UNIX socket	/var/run/mysqld/mysqld.sock
  Uptime:	7 sec
  Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 15.428
  root@xxxxxxxxxxxxxxxxxxxxx:~# stop mysql
  mysql stop/waiting
  root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql status
  * MySQL is stopped.
  
  This is horrible. The "status" commands report the wrong status and the start/stop commands do not work. If our operators are not super careful, our orchestration and monitoring system will go wild, report the wrong status and/or perform continuous restarts of the system as they think the service is not running. So we also fix it in trusty. the result will looks as below:
  ubuntu@maas:~/work/deb$ sudo start mysql
  mysql start/running, process 8523
  ubuntu@maas:~/work/deb$ sudo status mysql
  mysql start/running, process 8523
  ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql stop
  mysql stop/waiting
  ubuntu@maas:~/work/deb$ sudo status mysql
  mysql stop/waiting
  ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql status
  mysql stop/waiting
  
  [Regression Potential]
  
-  * Some scripts call '/etc/init.d/<service> reload' will not work if
- upstart script lacks a reload function and the reload function of
- /etc/init.d/<service> also uses PID. because it's managed by upstart now
- (the PID file does not exist). We should enumerate all those bad scripts
- and make them do the correct thing.
+ Some scripts call '/etc/init.d/<service> reload' will not work if
+ upstart script's 'reload signal' setting is incorrect and or
+ /etc/init.d/<service> requires special reload handling.  We should
+ enumerate all those bad scripts and make them do the correct thing.
+ 
+ At the same time, '/etc/init.d/<service> reload' is not a guaranteed
+ interface under Debian policy, and /etc/init.d/<service> force-reload
+ will work correctly for all packages; and if using the 'service'
+ command, this is already the existing behavior in trusty.

** 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/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.
  root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
  mysql start/running, process 5866
  root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql stop
  * Stopping MySQL database server mysqld [ OK ]
  root@xxxxxxxxxxxxxxxxxxxxx:~# status mysql
  mysql start/running, process 6101
  root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql status
  * /usr/bin/mysqladmin Ver 8.42 Distrib 5.5.43, for debian-linux-gnu on x86_64
  Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
  Oracle is a registered trademark of Oracle Corporation and/or its
  affiliates. Other names may be trademarks of their respective
  owners.
  Server version	5.5.43-0ubuntu0.14.04.1-log
  Protocol version	10
  Connection	Localhost via UNIX socket
  UNIX socket	/var/run/mysqld/mysqld.sock
  Uptime:	7 sec
  Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 15.428
  root@xxxxxxxxxxxxxxxxxxxxx:~# stop mysql
  mysql stop/waiting
  root@xxxxxxxxxxxxxxxxxxxxx:~# /etc/init.d/mysql status
  * MySQL is stopped.

  This is horrible. The "status" commands report the wrong status and the start/stop commands do not work. If our operators are not super careful, our orchestration and monitoring system will go wild, report the wrong status and/or perform continuous restarts of the system as they think the service is not running. So we also fix it in trusty. the result will looks as below:
  ubuntu@maas:~/work/deb$ sudo start mysql
  mysql start/running, process 8523
  ubuntu@maas:~/work/deb$ sudo status mysql
  mysql start/running, process 8523
  ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql stop
  mysql stop/waiting
  ubuntu@maas:~/work/deb$ sudo status mysql
  mysql stop/waiting
  ubuntu@maas:~/work/deb$ sudo /etc/init.d/mysql status
  mysql stop/waiting

  [Regression Potential]

  Some scripts call '/etc/init.d/<service> reload' will not work if
  upstart script's 'reload signal' setting is incorrect and or
  /etc/init.d/<service> requires special reload handling.  We should
  enumerate all those bad scripts and make them do the correct thing.

  At the same time, '/etc/init.d/<service> reload' is not a guaranteed
  interface under Debian policy, and /etc/init.d/<service> force-reload
  will work correctly for all packages; and if using the 'service'
  command, this is already the existing behavior in trusty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+subscriptions