fds closed after SIGCHLD bug still in newest version (fwd)

[Damien Miller]

On Wed, 22 Nov 2000 mouring at etoh.eviladmin.org wrote:

> On Thu, 23 Nov 2000, Pekka Savola wrote:
> 
> > On Wed, 22 Nov 2000, Markus Friedl wrote:
> > > can someone confirm this? it does not happen on openbsd.
> > 
> > Confirmed.  This happens only when using SSH2.  FreeBSD OpenSSH 2.2.0 ->
> > RHL 6.2 OpenSSH 2.3.0p2 (SNAP) fail as well as RHL 7.0 OpenSSH 2.3.0p1 ->
> > RHL 6.2 OpenSSH 2.3.0p2 (SNAP).
> > 
> Hmm... Does not fail under 2.4.0-test10 using Redhat 7.0
 
This is my understanding of the problem:

The problem is caused by my workaround for the sshd hand upon logout 
when background processes with open std{in,out,err} fd open.

On OpenBSD, when the child of sshd (which has children of its own) exits,
the stdout fd is marked as readable in the 
serverloop.c:wait_until_we_can_do_something select() and a subsequent read 
completes with a return value of 0.

On Linux, nothing is reported on the select() unit all grandchildren 
have exited (and thus closed their std* fds), then the child stdout fd
is marked as readable, but a subsequent read returns with a -1 and 
errno=EIO.

The workaround in the portable version was to allow a single pass through 
through the select (grep for child_has_selected in serverlop.c) and then
simulate a read failed on the channel (grep for djm in session.c).

The problem is that data may not have fully drained from the child before
the output is forcibly removed. The current strategy of giving the child
a chance to drain is broken: under high load, it may take a long time for
all the data to make it through, so any timelimit is arbitrary. 

Can anyone suggest a better solution?

-d

-- 
| ``We've all heard that a million monkeys banging on | Damien Miller -
| a million typewriters will eventually reproduce the | <djm at mindrot.org>
| works of Shakespeare. Now, thanks to the Internet, / 
| we know this is not true.'' - Robert Wilensky UCB / http://www.mindrot.org