[Bug 603363] Re: sshd never stops, prevents umount of /usr partition

Clint Byrum clint at fewbar.com
Sat Feb 12 16:58:09 UTC 2011


** Description changed:

  Under Ubuntu 10.04 Lucid, sshd is an upstart job controlled by
  /etc/init/ssh.conf  This file provides for start and stop as follows:
  
  start on filesystem
  stop on runlevel S
  
  At shutdown or reboot, therefore, sshd is not stopped.
  
  Since sshd is in /usr/sbin/sshd and also accesses lib files in /usr/lib
  this means that
  
  /etc/rc0.d/S40umountfs
  
  cannot successfully umount /usr at shutdown when /usr is on its own
  partition.
  
  This definitely leads to umount reporting errors in the shutdown console
  messages.
  
  It may also lead to fsck running on reboot and problems with mountall...
  I can't say for certain yet as I am also having problems umounting /var,
  possibly due to a power failure, which is what led me to notice and
  investigate these messages.
  
  My guess is that when sshd was a System V init process, it was killed by
  the killall5 process in /etc/rc0.d/S20sendsigs.  Under Lucid sshd has
  been made an upstart job and as such is exempt from the killall5 and so
  needs to be stopped explicitly.
  
  I admit I am by no means an expert on upstart or sshd, but the fix
  appears to me to be to modify /etc/init/ssh.conf to read
  
  stop on runlevel [!2345]
  
  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: openssh-server 1:5.3p1-3ubuntu4
  ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
  Uname: Linux 2.6.32-22-generic x86_64
  Architecture: amd64
  Date: Thu Jul  8 14:45:50 2010
  InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1)
  ProcEnviron:
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  SourcePackage: openssh
+ 
+ == SRU Report ==
+ 
+ === Impact / Justification ===
+ 
+ This bug can lead to filesystem corruption if /usr is on a separate
+ filesystem or if sshd isn't restarted on libc6 upgrade (which is almost
+ guaranteed due to bug #531912)
+ 
+ === Dev fix ===
+ 
+ This was fixed in the dev branch by making sshd stop on runlevel
+ [!2345], which is fairly standard for network services.
+ 
+ === Patch ===
+ 
+ See attached debdiff
+ 
+ === TEST CASE: ===
+ 
+ On a lucid system with all updates applied
+ 1. sudo apt-get install openssh-server
+ 2. verify it is started and running with 'sudo status ssh'
+ 3. sudo apt-get install --reinstall libc6
+ 4. If portmap is installed, Manually stop the portmap daemon which has a similar problem (sudo stop portmap)
+ 5. upon reboot, look in dmesg for the word 'Orphaned' 
+ 6. upgrade system and repeat steps 3-5, you should not see Orphaned anymore
+ 
+ === REGRESSION POTENTIAL ===
+ 
+ Its possible that people expect sshd to still be reachable until the
+ network is shutdown, which is fairly late in the shutdown process.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/603363

Title:
  sshd never stops, prevents umount of /usr partition

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

Bug description:
  Under Ubuntu 10.04 Lucid, sshd is an upstart job controlled by
  /etc/init/ssh.conf  This file provides for start and stop as follows:

  start on filesystem
  stop on runlevel S

  At shutdown or reboot, therefore, sshd is not stopped.

  Since sshd is in /usr/sbin/sshd and also accesses lib files in
  /usr/lib this means that

  /etc/rc0.d/S40umountfs

  cannot successfully umount /usr at shutdown when /usr is on its own
  partition.

  This definitely leads to umount reporting errors in the shutdown
  console messages.

  It may also lead to fsck running on reboot and problems with
  mountall... I can't say for certain yet as I am also having problems
  umounting /var, possibly due to a power failure, which is what led me
  to notice and investigate these messages.

  My guess is that when sshd was a System V init process, it was killed
  by the killall5 process in /etc/rc0.d/S20sendsigs.  Under Lucid sshd
  has been made an upstart job and as such is exempt from the killall5
  and so needs to be stopped explicitly.

  I admit I am by no means an expert on upstart or sshd, but the fix
  appears to me to be to modify /etc/init/ssh.conf to read

  stop on runlevel [!2345]

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: openssh-server 1:5.3p1-3ubuntu4
  ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
  Uname: Linux 2.6.32-22-generic x86_64
  Architecture: amd64
  Date: Thu Jul  8 14:45:50 2010
  InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1)
  ProcEnviron:
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: openssh

  == SRU Report ==

  === Impact / Justification ===

  This bug can lead to filesystem corruption if /usr is on a separate
  filesystem or if sshd isn't restarted on libc6 upgrade (which is
  almost guaranteed due to bug #531912)

  === Dev fix ===

  This was fixed in the dev branch by making sshd stop on runlevel
  [!2345], which is fairly standard for network services.

  === Patch ===

  See attached debdiff

  === TEST CASE: ===

  On a lucid system with all updates applied
  1. sudo apt-get install openssh-server
  2. verify it is started and running with 'sudo status ssh'
  3. sudo apt-get install --reinstall libc6
  4. If portmap is installed, Manually stop the portmap daemon which has a similar problem (sudo stop portmap)
  5. upon reboot, look in dmesg for the word 'Orphaned' 
  6. upgrade system and repeat steps 3-5, you should not see Orphaned anymore

  === REGRESSION POTENTIAL ===

  Its possible that people expect sshd to still be reachable until the
  network is shutdown, which is fairly late in the shutdown process.





More information about the Ubuntu-sponsors mailing list