Hi Catalin,
Sorry for taking so long to get back on this. I've committed
it now, slightly changed the check_close case since there's
no point waiting to flush data to an exited child.
Cheers,
Matt
On Sun, Aug 25, 2013 at 03:37:38AM -0400, Catalin Patulea wrote:
> ping?
>
> On Fri, Jul 26, 2013
ping?
On Fri, Jul 26, 2013 at 9:31 PM, Matt Johnston wrote:
> Hi Catalin,
>
> Thanks for looking at that - the last patch looks sensible, I'll give it a
> good test. There are a lot of subtle scenarios in channel closing (and
> variations between OSes).
>
> Cheers,
> Matt
>
> Catalin Patulea wro
Hi Catalin,
Thanks for looking at that - the last patch looks sensible, I'll give it a good
test. There are a lot of subtle scenarios in channel closing (and variations
between OSes).
Cheers,
Matt
Catalin Patulea wrote:
>Hm, that broke channel-close-by-child-exit. One more try, where we
>che
Hm, that broke channel-close-by-child-exit. One more try, where we
check for the child exiting and close writefd as a result. If writefd
is the last remaining open pipe to the child, then we also close the
channel as a whole.
On Wed, Jul 17, 2013 at 3:25 PM, Catalin Patulea wrote:
> Attached patc
Attached patch should fix both, and use hard tabs so should apply easily.
Rather than replacing readfd with writefd, *both* are checked for
FD_CLOSED before closing the entire channel. Then each direction can
be initially closed independently.
On Wed, Jul 17, 2013 at 7:57 PM, Catalin Patulea wro
dbclient handling of remote EOF/local not at EOF also appears broken:
openssh:
$ ssh -v root@1.2.3.4 'exec cat >/dev/null 2>/dev/null'
[...]
debug1: Entering interactive session.
debug1: Sending command: exec cat >/dev/null 2>/dev/null
# remote has sent EOF by virtue of &>/dev/null, but local->rem
Maybe the check on common-channel.c:338 should be against writefd
instead of readfd? This would get set by
close_chan_fd(channel->writefd) once recv_eof happens.
This patch indeed causes 'foo' to surface after input EOF:
diff -r 69cb561cc4c4 common-channel.c
--- a/common-channel.c Sat Jul 13 11:5
Hi,
I'm seeing a difference in how dbclient handles EOF on input compared
to openssh client. openssh client propagates input EOF to the remote
command, but continues pumping command stdout. dbclient seems to abort
before flushing the stdout buffer.
In the following examples, 1.2.3.4 is an openwrt
