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

[Launchpad Bug Tracker]

This bug was fixed in the package openssh - 1:5.3p1-3ubuntu7

---------------
openssh (1:5.3p1-3ubuntu7) lucid-proposed; urgency=low

  [ Clint Byrum ]
  * debian/openssh-server.ssh.init: Adding upstart awareness that will
    call /lib/init/upstart-job when script is run outside of a chroot.
    While this fixes LP: #531912, the change should be reverted when
    upstart gains chroot session support.

  [ Colin Watson ]
  * Only do the above if /etc/init/ssh.conf still exists, since apparently
    some people have been removing it.
 -- Clint Byrum <clint at ubuntu.com>   Fri, 10 Jun 2011 22:46:07 -0700

** Changed in: openssh (Ubuntu Lucid)
       Status: Fix Committed => Fix Released

** Changed in: openssh (Ubuntu Maverick)
       Status: Fix Committed => Fix Released

-- 
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 Released
Status in “openssh” source package in Maverick:
  Fix Released

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