sshd stops accepting new connections after configuration reload

Bug #1306877 reported by TAKAHASHI Shuhei
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Fix Released
Critical
Robie Basak

Bug Description

When upstart is enabled, sshd stops accepting new connections after reloading configuration by "initctl reload ssh".

It looks like sshd is frozen with SIGSTOP after receiving SIGHUP.

[nya@sora ~]% ps auxww | grep sshd
root 10557 0.0 0.1 61364 3056 ? Ss 13:46 0:00 /usr/sbin/sshd -D
[nya@sora ~]% sudo strace -p 10557
Process 10557 attached
select(7, [3 4], NULL, NULL, NULL^CProcess 10557 detached
 <detached ...>
[nya@sora ~]% sudo reload ssh
[nya@sora ~]% sudo strace -p 10557
Process 10557 attached
--- stopped by SIGSTOP ---

I guess it's caused by a Debian-specific patch: debian/patches/sigstop.patch. The patch makes sshd STOP when it's ready to start and have upstart resume it by specifying "expect stop" in /etc/init/ssh.conf. On receiving SIGHUP sshd re-executes itself and STOPs again, but upstart does not perform resume.

Reproduced under Ubuntu 14.04 Trusty
Package version: openssh 1:6.6p1-2

Tags: patch
Revision history for this message
TAKAHASHI Shuhei (nya3jp) wrote :

This is the change I mentioned above:
https://github.com/nya3jp/openssh-debian/commit/0334ce32304e9ba2a10ee5ca49ca6e8ff3ba6cf4

As a workaround, I commented out these two lines in /etc/init/ssh.conf:
  # env SSH_SIGSTOP=1
  # expect stop

Now "initctl reload ssh" works fine, though I'm not really sure I'm doing a "right" thing.

Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Setting Importance to Critical as this is an expected harmless operation that will render the system essentially unreachable (and thus unusable) for remote users (eg. just about all server users).

It seems to me that the STOP patch should only activate on first run, not on a re-exec. I'll take a look.

Revision history for this message
Robie Basak (racb) wrote :

(confirmed on Trusty 1:6.6p1-2)

Changed in openssh (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Robie Basak (racb)
Changed in openssh (Ubuntu):
assignee: nobody → Robie Basak (racb)
Revision history for this message
Robie Basak (racb) wrote :

openssh in Saucy (1:6.2p2-6ubuntu0.1) doesn't have this issue. Looks like its upstart job doesn't set SSH_SIGSTOP, use "expect stop", and doesn't have the patch.

So I think the bug is in the patch applied in Trusty. Fix attached. It seems to work. I'd appreciate a review of what I've done, though.

Colin Watson (cjwatson)
Changed in openssh (Ubuntu):
status: Triaged → Fix Committed
tags: added: patch
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:6.6p1-2ubuntu1

---------------
openssh (1:6.6p1-2ubuntu1) trusty; urgency=medium

  * Upload from Debian git repository to fix a release-critical bug.
  * Debconf translations:
    - French (thanks, Étienne Gilli; closes: #743242).
  * Never signal the service supervisor with SIGSTOP more than once, to
    prevent a hang on re-exec (thanks, Robie Basak; LP: #1306877).
 -- Colin Watson <email address hidden> Mon, 14 Apr 2014 12:20:48 +0100

Changed in openssh (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.