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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox