[Bug 531912] Re: /etc/init.d/ssh seems to work, but actually upstart is used.

[Rolf Leggewie]

Thanks to everyone involved in getting this fixed.  I'll say that I
still don't have much confidence in all of this, but judging by the test
case, it seems that at least for my lucid system there is no longer a
discrepancy between the status managed with init.d and upstart.  Please
release to -updates.

As a user I'm thankful for all the work the devs do.  I think it's quite
obvious from what Ubuntu has achieved that everybody involved is really
trying their best and it mostly works extremely well.  But I will not
hide the fact that I also feel that upstart was very hastily introduced
WAY before it's time.  Dapper vservers are still stuck without ANY
upgrade path AT ALL because of upstart.  I feel this is quite outrageous
given the promise of an LTS.  There isn't much live left for dapper
users and obviously, I'd much rather run lucid by now.  I hope bug
430224 will soon get fixed for lucid.

So, thanks again to the devs for their work.  Sometimes you can't win, I
guess ;-)

** Tags added: verification-done
** Tags removed: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/531912

Title:
  /etc/init.d/ssh seems to work, but actually upstart is used.

Status in “openssh” package in Ubuntu:
  Fix Released
Status in “openssh” source package in Lucid:
  Fix Committed
Status in “openssh” source package in Maverick:
  Fix Committed

Bug description:
  While trying to get x-forwarding on Lucid to work, I edited
  /etc/default/ssh to add the -4 flag, as offered as a work-around in
  various bugreports. When trying to restart ssh using /etc/init.d/ssh,
  all seems to work but my flags around passed to sshd.

  It seems that ssh is actually managed by upstart, which is great, but
  you cannot really tell. For other services, there are symlinks to
  /lib/init, for ssh there isn't. So I assumed that ssh is still managed
  using /etc/init.d/

  Please clarify the use of upstart (for ssh) for users, so they don't
  spend hours trying to debug what shouldn't be debugged. :)

  == SRU Justification ==

  Impact: this bug causes quite a bit of confusion for users, which is
  particularly troubling considering SSH is often the only way headless
  systems can be accessed post-installation. The change will avoid the
  half-in half-out situation that some people are dealing with where
  they mix /etc/init.d/ssh with using the 'service' command or upstart
  start/stop/initctl commands.

  Dev fix: A check has been added to the included init.d script which
  checks to see if it is being run in a chroot, and if not, it runs
  /lib/init/upstart-job in much the same way it is usually run when
  symlinked from /etc/init.d.

  TEST CASE:

  1. start a system with openssh-server installed
  2. run 'sudo status ssh' to verify that ssh has been started by upstart.
  3. run 'sudo stop ssh' to stop the upstart job.
  4. run 'sudo /etc/init.d/ssh start'. It should start sshd without upstart.
  5. run 'sudo status ssh' to verify that the ssh upstart job is not running
  6. run 'sudo /etc/int.d/ssh stop' to stop the incorrectly managed sshd.
  7. install new package with patched init.d script
  8. repeat steps 2 through 4. now it should display a disclaimer like this:
  Rather than invoking init scripts through /etc/init.d, use the service(8)
  utility, e.g. service ssh start

  Since the script you are attempting to invoke has been converted to an
  Upstart job, you may also use the start(8) utility, e.g. start ssh

  
  Regression Potential:

  There may be users who are expecting this script to work outside of
  chroots. They would have to achieve this by modifying the start on or
  removing the /etc/init/ssh.conf. The latter case is handled directly
  in the code by checking for its existence. The former will also be
  handled on reboot, but not on upgrades. The upgrade will cause the
  script to be unable to stop any sshd that is running via the old
  method.

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