| 2010-12-08 21:14:22 |
AlainKnaff |
bug |
|
|
added bug |
| 2010-12-08 21:25:59 |
Serge Hallyn |
openssh (Ubuntu): status |
New |
Confirmed |
|
| 2010-12-08 21:27:22 |
Serge Hallyn |
bug task added |
|
upstart |
|
| 2010-12-08 21:28:37 |
Serge Hallyn |
openssh (Ubuntu): importance |
Undecided |
Low |
|
| 2010-12-09 06:29:43 |
Clint Byrum |
bug |
|
|
added subscriber Clint Byrum |
| 2010-12-09 06:29:45 |
Clint Byrum |
openssh (Ubuntu): importance |
Low |
High |
|
| 2010-12-09 16:07:30 |
Serge Hallyn |
bug |
|
|
added subscriber Serge Hallyn |
| 2010-12-09 23:30:46 |
Brian Murray |
nominated for series |
|
Ubuntu Lucid |
|
| 2010-12-09 23:30:46 |
Brian Murray |
bug task added |
|
openssh (Ubuntu Lucid) |
|
| 2010-12-09 23:30:46 |
Brian Murray |
nominated for series |
|
Ubuntu Maverick |
|
| 2010-12-09 23:30:46 |
Brian Murray |
bug task added |
|
openssh (Ubuntu Maverick) |
|
| 2010-12-09 23:36:07 |
Brian Murray |
openssh (Ubuntu Lucid): status |
New |
Confirmed |
|
| 2010-12-09 23:36:10 |
Brian Murray |
openssh (Ubuntu Maverick): status |
New |
Confirmed |
|
| 2010-12-09 23:36:12 |
Brian Murray |
openssh (Ubuntu Lucid): importance |
Undecided |
High |
|
| 2010-12-09 23:36:15 |
Brian Murray |
openssh (Ubuntu Maverick): importance |
Undecided |
High |
|
| 2010-12-13 22:08:30 |
Launchpad Janitor |
branch linked |
|
lp:~clint-fewbar/ubuntu/natty/openssh/upstart-noexpect |
|
| 2010-12-13 22:14:22 |
Clint Byrum |
openssh (Ubuntu): assignee |
|
Clint Byrum (clint-fewbar) |
|
| 2010-12-14 12:00:11 |
Launchpad Janitor |
openssh (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2010-12-28 16:46:48 |
Imre Gergely |
bug |
|
|
added subscriber Imre Gergely |
| 2010-12-28 19:41:29 |
Imre Gergely |
description |
When sshd gets a signal 1 for reload, it forks a new process and ditches the old. This causes upstart to believe that ssh has crashed, and loses track of it. A second reload (or any other initctl operation on ssh) will thus say:
reload: Unknown instance:
There would be 2 ways to fix this:
1. Don't have ssh fork on relod, but keep the same pid
2. Use a different mechanism in upstart to keep track of ssh. Maybe a pid file? Just tracking children of the exited ssh won't work, or it might accidentally track a particular session rather than the master, if somebody just happens to log in close to reload time.
# lsb_release -rd
Description: Ubuntu 10.04.1 LTS
Release: 10.04
# dpkg -l openssh-server | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-===========================================-==========================================================-=================================================================
ii openssh-server 1:5.3p1-3ubuntu4 secure shell (SSH) server, for secure access from remote machines
# dpkg -l upstart
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii upstart 0.6.5-7 event-based init daemon |
When sshd gets a signal 1 for reload, it forks a new process and ditches the old. This causes upstart to believe that ssh has crashed, and loses track of it. A second reload (or any other initctl operation on ssh) will thus say:
reload: Unknown instance:
There would be 2 ways to fix this:
1. Don't have ssh fork on relod, but keep the same pid
2. Use a different mechanism in upstart to keep track of ssh. Maybe a pid file? Just tracking children of the exited ssh won't work, or it might accidentally track a particular session rather than the master, if somebody just happens to log in close to reload time.
openssh-server 1:5.3p1-3ubuntu4
upstart 0.6.5-7
==== Info for Maverick, Lucid SRU ====
IMPACT: if sshd gets a HUP signal, it forks a new process and upstart thinks the process died and loses track of it, so the user/admin uses the ability to stop/start/reload the daemon through upstart.
The problem is fixed in Natty 5.6p1-2ubuntu3. See attached patches for Maverick and Lucid.
TEST CASE:
- install openssh-server
- send a HUP signal to sshd
- the daemon is restarted, but upstart thinks that it crashed (/var/log/daemon.log):
Dec 28 20:59:57 utest-lls32 init: ssh main process ended, respawning
Dec 28 20:59:57 utest-lls32 init: ssh main process (1451) terminated with status 255
Dec 28 20:59:57 utest-lls32 init: ssh main process ended, respawning
Dec 28 20:59:57 utest-lls32 init: ssh main process (1455) terminated with status 255
Dec 28 20:59:57 utest-lls32 init: ssh respawning too fast, stopped
- after this, upstart won't know about sshd, despite the daemon running just fine:
root@utest-lls32:~# reload ssh
reload: Unknown instance:
With the fix applied, the correct behavior is:
- send a HUP signal to sshd
ps ax |grep sshd
kill -HUP sshd
- the daemon reloads (/var/log/auth.log):
Dec 28 21:37:01 utest-lls32 sshd[742]: Received SIGHUP; restarting.
Dec 28 21:37:01 utest-lls32 sshd[742]: Server listening on 0.0.0.0 port 22.
Dec 28 21:37:01 utest-lls32 sshd[742]: Server listening on :: port 22.
- reloading with upstart gives the same result, and NOT an error message.
REGRESSION POTENTIAL: TODO |
|
| 2010-12-28 19:46:18 |
Imre Gergely |
attachment added |
|
Debdiff for Lucid https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/687535/+attachment/1778353/+files/lucid.debdiff |
|
| 2010-12-28 19:50:13 |
Imre Gergely |
attachment added |
|
Debdiff for Maverick https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/687535/+attachment/1778359/+files/maverick.debdiff |
|
| 2010-12-28 20:38:19 |
Clint Byrum |
tags |
|
patch |
|
| 2010-12-28 20:42:12 |
Clint Byrum |
description |
When sshd gets a signal 1 for reload, it forks a new process and ditches the old. This causes upstart to believe that ssh has crashed, and loses track of it. A second reload (or any other initctl operation on ssh) will thus say:
reload: Unknown instance:
There would be 2 ways to fix this:
1. Don't have ssh fork on relod, but keep the same pid
2. Use a different mechanism in upstart to keep track of ssh. Maybe a pid file? Just tracking children of the exited ssh won't work, or it might accidentally track a particular session rather than the master, if somebody just happens to log in close to reload time.
openssh-server 1:5.3p1-3ubuntu4
upstart 0.6.5-7
==== Info for Maverick, Lucid SRU ====
IMPACT: if sshd gets a HUP signal, it forks a new process and upstart thinks the process died and loses track of it, so the user/admin uses the ability to stop/start/reload the daemon through upstart.
The problem is fixed in Natty 5.6p1-2ubuntu3. See attached patches for Maverick and Lucid.
TEST CASE:
- install openssh-server
- send a HUP signal to sshd
- the daemon is restarted, but upstart thinks that it crashed (/var/log/daemon.log):
Dec 28 20:59:57 utest-lls32 init: ssh main process ended, respawning
Dec 28 20:59:57 utest-lls32 init: ssh main process (1451) terminated with status 255
Dec 28 20:59:57 utest-lls32 init: ssh main process ended, respawning
Dec 28 20:59:57 utest-lls32 init: ssh main process (1455) terminated with status 255
Dec 28 20:59:57 utest-lls32 init: ssh respawning too fast, stopped
- after this, upstart won't know about sshd, despite the daemon running just fine:
root@utest-lls32:~# reload ssh
reload: Unknown instance:
With the fix applied, the correct behavior is:
- send a HUP signal to sshd
ps ax |grep sshd
kill -HUP sshd
- the daemon reloads (/var/log/auth.log):
Dec 28 21:37:01 utest-lls32 sshd[742]: Received SIGHUP; restarting.
Dec 28 21:37:01 utest-lls32 sshd[742]: Server listening on 0.0.0.0 port 22.
Dec 28 21:37:01 utest-lls32 sshd[742]: Server listening on :: port 22.
- reloading with upstart gives the same result, and NOT an error message.
REGRESSION POTENTIAL: TODO |
When sshd gets a signal 1 for reload, it forks a new process and ditches the old. This causes upstart to believe that ssh has crashed, and loses track of it. A second reload (or any other initctl operation on ssh) will thus say:
reload: Unknown instance:
There would be 2 ways to fix this:
1. Don't have ssh fork on relod, but keep the same pid
2. Use a different mechanism in upstart to keep track of ssh. Maybe a pid file? Just tracking children of the exited ssh won't work, or it might accidentally track a particular session rather than the master, if somebody just happens to log in close to reload time.
openssh-server 1:5.3p1-3ubuntu4
upstart 0.6.5-7
==== Info for Maverick, Lucid SRU ====
IMPACT: if sshd gets a HUP signal, it forks a new process and upstart thinks the process died and loses track of it, so the user/admin uses the ability to stop/start/reload the daemon through upstart.
The problem is fixed in Natty 5.6p1-2ubuntu3. See attached patches for Maverick and Lucid.
TEST CASE:
- install openssh-server
- send a HUP signal to sshd
- the daemon is restarted, but upstart thinks that it crashed (/var/log/daemon.log):
Dec 28 20:59:57 utest-lls32 init: ssh main process ended, respawning
Dec 28 20:59:57 utest-lls32 init: ssh main process (1451) terminated with status 255
Dec 28 20:59:57 utest-lls32 init: ssh main process ended, respawning
Dec 28 20:59:57 utest-lls32 init: ssh main process (1455) terminated with status 255
Dec 28 20:59:57 utest-lls32 init: ssh respawning too fast, stopped
- after this, upstart won't know about sshd, despite the daemon running just fine:
root@utest-lls32:~# reload ssh
reload: Unknown instance:
With the fix applied, the correct behavior is:
- send a HUP signal to sshd
ps ax |grep sshd
kill -HUP sshd
- the daemon reloads (/var/log/auth.log):
Dec 28 21:37:01 utest-lls32 sshd[742]: Received SIGHUP; restarting.
Dec 28 21:37:01 utest-lls32 sshd[742]: Server listening on 0.0.0.0 port 22.
Dec 28 21:37:01 utest-lls32 sshd[742]: Server listening on :: port 22.
- reloading with upstart gives the same result, and NOT an error message.
REGRESSION POTENTIAL:
There is a small race condition in sshd between when it forks, and when it listens for incoming connections. The length of the race is lengthened by a very tiny amount by considering sshd started as soon as it has been executed, rather than when it forks. This will only affect jobs that use 'start on started ssh' and immediately connect to it. This is unlikely to cause problems in any real world scenario, given that most of these programs would also have to fork, exec, and open a socket, which is more work than what sshd will be doing in that time.
|
|
| 2010-12-28 20:42:26 |
Clint Byrum |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2010-12-28 20:43:20 |
Clint Byrum |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2011-01-07 10:20:54 |
Launchpad Janitor |
branch linked |
|
lp:~cjwatson/ubuntu/lucid/openssh/lucid-proposed |
|
| 2011-01-07 10:24:31 |
Launchpad Janitor |
branch linked |
|
lp:~cjwatson/ubuntu/maverick/openssh/maverick-proposed |
|
| 2011-01-07 10:25:12 |
Colin Watson |
openssh (Ubuntu Lucid): status |
Confirmed |
In Progress |
|
| 2011-01-07 10:25:18 |
Colin Watson |
openssh (Ubuntu Maverick): status |
Confirmed |
In Progress |
|
| 2011-01-07 14:48:58 |
Jan Tijssen |
bug |
|
|
added subscriber Jan Tijssen |
| 2011-01-07 14:49:46 |
Jan Tijssen |
removed subscriber Jan Tijssen |
|
|
|
| 2011-01-08 12:58:13 |
Benjamin Drung |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2011-01-09 12:06:04 |
Martin Pitt |
openssh (Ubuntu Maverick): status |
In Progress |
Fix Committed |
|
| 2011-01-09 12:06:11 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2011-01-09 12:06:17 |
Martin Pitt |
tags |
patch |
patch verification-needed |
|
| 2011-01-09 12:11:46 |
Martin Pitt |
openssh (Ubuntu Lucid): status |
In Progress |
Fix Committed |
|
| 2011-01-10 03:59:10 |
Martin Pitt |
tags |
patch verification-needed |
patch verification-done verification-needed |
|
| 2011-01-23 10:06:26 |
Launchpad Janitor |
openssh (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2011-01-23 10:07:39 |
Colin Watson |
tags |
patch verification-done verification-needed |
patch verification-needed |
|
| 2011-01-25 20:48:27 |
Martin Pitt |
tags |
patch verification-needed |
patch verification-done |
|
| 2011-01-26 06:37:01 |
Launchpad Janitor |
openssh (Ubuntu Maverick): status |
Fix Committed |
Fix Released |
|
| 2011-02-08 01:15:19 |
Clint Byrum |
upstart: status |
New |
Invalid |
|
| 2011-02-23 05:26:58 |
Mark Goris |
bug |
|
|
added subscriber gorism |
| 2011-09-19 21:40:54 |
Ubuntu Foundations Team Bug Bot |
tags |
patch verification-done |
patch testcase verification-done |
|
