From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-kernel@vger.kernel.org
Subject: Re: Data sitting and remaining in Send-Q
Date: Mon, 24 Dec 2001 20:00:21 +0100 [thread overview]
Message-ID: <20011224200021.F2461@lug-owl.de> (raw)
In-Reply-To: <20011224180142.E2461@lug-owl.de> <20011224181031.GA7934@localhost>
In-Reply-To: <20011224181031.GA7934@localhost>
On Mon, 2001-12-24 19:10:32 +0100, José Luis Domingo López <jdomingo@internautas.org>
wrote in message <20011224181031.GA7934@localhost>:
> On Monday, 24 December 2001, at 18:01:42 +0100,
> Jan-Benedict Glaw wrote:
>
> > I've got some problem with a freshly installed Debian sid system.
> > It's running with 2.4.16, 2.4.17-rc2 and 2.4.17 (the problem
> > appears on all these kernels) and something seems to break ssh.
> >
> I don't know if this has something to do with your problem, but
> bugs.debian.org has a _long_ list of reported bugs for ssh, many of them
> with respect to ssh's X-forwarding.
Yes, I know, and it's not only connected to X forwording, but also
(this is the majority of filed bugs) with ssh's exit behaviour
when any processes where started in background. However -- I've
got this problem with the running, interactive session. If I make
the server to send more than maybe 200 byte or so, the session
will hang, with both sides sitting in select, and data on the
server's Send-Q...
> My own experience with Debian's ssh is that, sooner or later,
> X-forwarding fails, with Send-Q (or Recv-Q) in the server side
> completely full. The server side was Debian Sid, and client side was
> Debian Woody, and it happened with both a simple xclock and gkrellm (ssh
> remoteserver xclock, ssh remoteserver gkrellm).
Well, my understanding is that, if there's data in any of the queues,
these bytes should be delivered. In this case, data is *not* sent
over the wire. Is this a kernel bug? ...or is data only transmitted
if we're in position to also set the PUSH bit?
> However, interactive shells didn't seem to show this problem.
Mine does:-( And this is quite annoying, because I'm to present
some software on the box in question in some days. But, with
no ssh on a (so far) headless box, I'll face some trouble...
MfG, JBG
--
Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481
-- New APT-Proxy written in shell script --
http://lug-owl.de/~jbglaw/software/ap2/
next prev parent reply other threads:[~2001-12-24 19:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-24 17:01 Data sitting and remaining in Send-Q Jan-Benedict Glaw
2001-12-24 18:10 ` José Luis Domingo López
2001-12-24 19:00 ` Jan-Benedict Glaw [this message]
2001-12-24 19:38 ` Jan-Benedict Glaw
2001-12-24 20:09 ` Mr. James W. Laferriere
2001-12-24 20:17 ` Jan-Benedict Glaw
2001-12-24 20:44 ` Alex Bligh - linux-kernel
2001-12-24 21:34 ` Thorsten Kranzkowski
2001-12-24 21:58 ` Jan-Benedict Glaw
2001-12-24 21:56 ` Jan-Benedict Glaw
2001-12-25 0:43 ` Alex Bligh - linux-kernel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011224200021.F2461@lug-owl.de \
--to=jbglaw@lug-owl.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.