** Tags added: testcase
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/687535
Title:
upstart loses track of ssh daemon after reload ssh
To manage notifications about this bug go
We did as described above, and the log files did not yield any helpful
information. My next step is to revert back to openssh_5.3p1-3ubuntu4,
since that seemed to be reliable.
As for the fact that this didn't show up in any testing prior to
committing the patch, I would point out that, just
It is an EBS root instance, and I'll be spinning up a replacement
instance as a next step. I'll mount a snapshot of root, check out
/var/log, and let you know what I find.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in
I just updated to the openssh-server_5.3p1-3ubuntu5 package for a Lucid
instance, and now I can't get SSH to start. Or, rather, I'm running
into what Jan mentioned above, with the respawning/terminating loop that
eventually results in init deciding that SSH isn't going to start, and
giving up.
On Wed, 2011-02-23 at 05:19 +, gorism wrote:
I just updated to the openssh-server_5.3p1-3ubuntu5 package for a Lucid
instance, and now I can't get SSH to start. Or, rather, I'm running
into what Jan mentioned above, with the respawning/terminating loop that
eventually results in init
I'm closing the upstart bug task as Invalid.
Upstart is doing what it was designed to do, following fork()'d pids.
This method just can't handle things that re-fork arbitrarily.
** Changed in: upstart
Status: New = Invalid
--
You received this bug notification because you are a member
I'm not convinced this is true, Clint. Should upstart jobs be allowed
to spawn processes that then get orphaned from the POV of the process
supervisor? Maybe upstart shouldn't be tracking the new PID, but maybe
it should instead be reaping any children left behind?
--
You received this bug
They definitely should be allowed, ssh is actually a canon example of
why.
Upstart should supervise the sshd daemon, not the login sub-process
associated with a particular connection, and certainly not any
processes being run inside the login session.
Otherwise stop ssh would kill all user
On Tue, Feb 08, 2011 at 04:14:59AM -, Scott James Remnant wrote:
They definitely should be allowed, ssh is actually a canon example of
why.
Upstart should supervise the sshd daemon, not the login sub-process
associated with a particular connection, and certainly not any
processes being
That being said, the current process tracker is very much not ideal.
I'm working on a new one, and will probably post in this week in the
form of a test program to be run and played with.
Scott
On Mon, Feb 7, 2011 at 8:48 PM, Steve Langasek
steve.langa...@canonical.com wrote:
On Tue, Feb 08,
I'm sorry to spoil the fun but I see the same problem on Lucid with the
new package.
Only thing that might be of interest is that this is a xen 4 guest.
More info and tests available on request.
root@somehost:/var/log (zcat daemon.log.3.gz ; zcat daemon.log.2.gz ; cat
daemon.log.1 ; cat
Hrmmm
Feb 2 12:01:33 somehost sshd[379]: error: Bind to port 22 on 1.2.3.4 failed:
Cannot assign requested address.
Feb 2 12:01:33 somehost sshd[379]: error: Bind to port 22 on
:666:77:::1 failed: Cannot assign requested address.
Feb 2 12:01:33 somehost sshd[379]: fatal: Cannot
Jan, do you have a pidfile for sshd in /var/run ?
If so, you may have hit bug #531912 by running the init.d script.
Try
/etc/init.d/ssh stop
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
Confirmed fixed on Maverick.
root@utest-mms32:~# lsb_release -rd
Description:Ubuntu 10.10
Release:10.10
root@utest-mms32:~# apt-cache policy openssh-server
openssh-server:
Installed: 1:5.5p1-4ubuntu5
Candidate: 1:5.5p1-4ubuntu5
Version table:
*** 1:5.5p1-4ubuntu5 0
500
** Tags added: verification-done
** Tags removed: verification-needed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
https://bugs.launchpad.net/bugs/687535
Title:
upstart loses track of ssh daemon after reload
This bug was fixed in the package openssh - 1:5.5p1-4ubuntu5
---
openssh (1:5.5p1-4ubuntu5) maverick-proposed; urgency=low
* debian/openssh-server.ssh.upstart: drop 'expect fork' and run sshd
with -D to avoid losing track on reload (LP: #687535)
-- Imre Gergely
Benjamin, no, I didn't - I sponsored it myself and it wasn't necessary
to add it to the general sponsoring queue.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
https://bugs.launchpad.net/bugs/687535
Title:
This bug was fixed in the package openssh - 1:5.3p1-3ubuntu5
---
openssh (1:5.3p1-3ubuntu5) lucid-proposed; urgency=low
* debian/openssh-server.ssh.upstart: drop 'expect fork' and run sshd
with -D to avoid losing track on reload (LP: #687535)
-- Imre Gergely gi...@narancs.net
Released for lucid (thanks, Simon!); still needs verification for
maverick.
** Tags removed: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
https://bugs.launchpad.net/bugs/687535
Title:
upstart
Accepted openssh into maverick-proposed, the package will build now and
be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
** Changed in: openssh (Ubuntu
Accepted openssh into lucid-proposed, the package will build now and be
available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
** Changed in: openssh (Ubuntu Lucid)
I confirm that this bug is fixed on Lucid.
$ lsb_release -rd
Description:Ubuntu 10.04.1 LTS
Release:10.04
$ apt-cache policy openssh-server
openssh-server:
Installed: 1:5.3p1-3ubuntu5
Candidate: 1:5.3p1-3ubuntu5
Version table:
*** 1:5.3p1-3ubuntu5 0
500
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
https://bugs.launchpad.net/bugs/687535
Title:
upstart loses track of ssh daemon after reload ssh
--
Ubuntu-server-bugs mailing
Colin, you forgot to unsubscribe ubuntu-sponsors.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
https://bugs.launchpad.net/bugs/687535
Title:
upstart loses track of ssh daemon after reload ssh
--
** Branch linked: lp:~cjwatson/ubuntu/lucid/openssh/lucid-proposed
** Branch linked: lp:~cjwatson/ubuntu/maverick/openssh/maverick-proposed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
Thanks, Imre! I've sponsored these two patches; they're waiting in the
SRU queue for approval now.
** Changed in: openssh (Ubuntu Lucid)
Status: Confirmed = In Progress
** Changed in: openssh (Ubuntu Maverick)
Status: Confirmed = In Progress
--
You received this bug notification
I'm guessing this is waiting for a SRU. Here's the patch for Lucid and
Maverick. Description updated for SRU. Please somebody add some notes to
'REGRESSION POTENTIAL' because I have no idea about that...
** Description changed:
When sshd gets a signal 1 for reload, it forks a new process and
** Patch added: Debdiff for Lucid
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/687535/+attachment/1778353/+files/lucid.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
** Patch added: Debdiff for Maverick
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/687535/+attachment/1778359/+files/maverick.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in ubuntu.
Thanks Imre!
I've updated the 'regression-potential' and subscribed ubuntu-sru and
ubuntu-sponsors.
** Tags added: patch
** Description changed:
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
Imre, the debdiffs need different changelog lines for SRU's
openssh (1:5.3p1-3ubuntu4.1) lucid-proposed; urgency=low
and
openssh (1:5.5p1-4ubuntu4.1) maverick-proposed; urgency=low
Otherwise they look good to me.
--
You received this bug notification because you are a member of Ubuntu
Server
Ah, then ssh already had that race.
In which case -D seems like a good choice
On Mon, Dec 13, 2010 at 11:05 PM, Clint Byrum cl...@fewbar.com wrote:
The code looks something like this:
[ option parsing, config check, etc ]
sshd.c, line 1744: daemon()
[ reinit logs, start random number
This bug was fixed in the package openssh - 1:5.6p1-2ubuntu3
---
openssh (1:5.6p1-2ubuntu3) natty; urgency=low
[ Clint Byrum ]
* debian/openssh-server.ssh.upstart: drop 'expect fork' and run sshd
with -D to avoid losing track on reload (LP: #687535)
[ Colin Watson ]
*
In looking at the code in OpenSSH, the -D flag only affects this portion
of sshd.c, around line 1740:
/*
* If not in debugging mode, and not started from inetd, disconnect
* from the controlling terminal, and fork. The original process
* exits.
*/
if (!(debug_flag ||
Not using expect fork of course would mean that ssh would be reported as
running before it was actually listening for connections.
On Mon, Dec 13, 2010 at 10:13 PM, Clint Byrum cl...@fewbar.com wrote:
In looking at the code in OpenSSH, the -D flag only affects this portion
of sshd.c, around
The code looks something like this:
[ option parsing, config check, etc ]
sshd.c, line 1744: daemon()
[ reinit logs, start random number generator, chdir to /, ignore SIGPIPE ]
sshd.c, line 1774: server_listen() -- socket(), bind(), listen(), etc.
So, there's already a race between considering
Alain, I meant Invalid in Upstart, and I'm sorry for the confusion.
There is no doubt in my mind that the ssh.conf needs some changes, and
should be fixed going back to Lucid.
The notion of pidfiles is generally rejected by the upstart community
because daemons don't get this right. I think the
** Also affects: openssh (Ubuntu Lucid)
Importance: Undecided
Status: New
** Also affects: openssh (Ubuntu Maverick)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in
** Changed in: openssh (Ubuntu Lucid)
Status: New = Confirmed
** Changed in: openssh (Ubuntu Maverick)
Status: New = Confirmed
** Changed in: openssh (Ubuntu Lucid)
Importance: Undecided = High
** Changed in: openssh (Ubuntu Maverick)
Importance: Undecided = High
--
You
Calling this low priority since
kill -9 `pidof sshd`
start ssh
is a workaround.
** Changed in: openssh (Ubuntu)
Status: New = Confirmed
** Also affects: upstart
Importance: Undecided
Status: New
** Changed in: openssh (Ubuntu)
Importance: Undecided = Low
--
You
So why bother having an upstart or init at all, and not start and stop
everything manually?
Similar issue exists with squid (bug 573853)
Upstart is a nice concept, and really improved boot times. It would
even be better if it was more reliable. These glitches break web
administration tools
Alain, I understand your frustration. This is actually I think a little
more serious than Low, as existence of a workaround only barely
mitigates the impact of this.
The problem, I think, is that we're using expect fork, and I'm not sure
why, when sshd has -D, and its clearly not reliable for
Also this is not really a new bug in upstart. It is related to bug
#530779 which causes issues when the parent dies, but its not the same
issue, and in fact, the proc connector probably wouldn't help because
the proc connector still doesn't solve the problem of knowing when this
fork is actually a
Alain, I understand your frustration. think a little more serious than
Low,
Thanks for your insight.
as existence of a workaround only barely mitigates the impact of this.
Just a note about this workaround: kill -9 `pidof sshd` will saw off
the branch on which you're sitting if you happen to
44 matches
Mail list logo