sshd stops accepting new connections after configuration reload

Bug #1306877 reported by TAKAHASHI Shuhei on 2014-04-12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
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

TAKAHASHI Shuhei (nya3jp) wrote :

This is the change I mentioned above:

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.

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.

Robie Basak (racb) wrote :

(confirmed on Trusty 1:6.6p1-2)

Changed in openssh (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Robie Basak (racb) on 2014-04-14
Changed in openssh (Ubuntu):
assignee: nobody → Robie Basak (racb)
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) on 2014-04-14
Changed in openssh (Ubuntu):
status: Triaged → Fix Committed
tags: added: patch
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  Edit
Everyone can see this information.

Other bug subscribers