Bug 30305

Summary:	non-fatal chan_read_failed messages in /var/log/messages
Product:	[Retired] Red Hat Linux	Reporter:	Derek Price <oberon>
Component:	openssh	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	7.0	CC:	pekkas
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-02-03 15:21:48 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Derek Price 2001-03-02 15:45:31 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-3-usb i686)


The following error messages are consistantly appearing in
/var/log/messages:

Mar  2 10:32:46 empress sshd[4309]: error: channel 0: internal error: we do
not read, but chan_read_failed for istate 8

Here is a longer snippet:
Mar  2 10:32:46 empress sshd[4309]: Accepted publickey for dprice from
10.0.0.1 port 1468 ssh2
Mar  2 10:32:46 empress sshd[4309]: error: channel 0: internal error: we do
not read, but chan_read_failed for istate 8
Mar  2 10:32:46 empress PAM_pwdb[4309]: (sshd) session closed for user
dprice
Mar  2 10:32:48 empress sshd[4315]: Accepted publickey for dprice from
10.0.0.1 port 1469 ssh2
Mar  2 10:32:49 empress sshd[4315]: error: channel 0: internal error: we do
not read, but chan_read_failed for istate 8
Mar  2 10:32:49 empress PAM_pwdb[4315]: (sshd) session closed for user
dprice
Mar  2 10:32:51 empress sshd[4321]: Accepted publickey for dprice from
10.0.0.1 port 1470 ssh2
Mar  2 10:32:51 empress sshd[4321]: error: channel 0: internal error: we do
not read, but chan_read_failed for istate 8
Mar  2 10:32:51 empress PAM_pwdb[4321]: (sshd) session closed for user
dprice

This is non-fatal, but ocassionally I am getting failed connections as part
of a test script (I have been unable to get a specific error message - the
test script is merely checking whether the output of "ssh -n localhost
'echo hi'" = "hi").  I don't know if these two issues are related.

Reproducible: Always
Steps to Reproduce:
1. ssh -n localhost 'echo hi'
2.
3.
	

Actual Results:  Mostly works, but the error message above appears in
/var/log/message.  Intermittant and possibly unrelated failures.

Expected Results:  No error message, no failures.

Comment 1 Derek Price 2001-03-02 16:05:30 UTC

Just managed to get the failure case on the command line.  In the failure case,
the "ssh -n empress.2-wit.com 'echo hi'" fails without outputting any text
whatsoever and the error message I pointed out _does not_ appear in the log,
interestingly enough.  I went back through /var/log/messages and confirmed the
lack of error message for one of the test script failure cases.

This has been happening consistantly during evening test runs, and the two cases
I recently managed to reproduce seem to happen after I haven't attempted opening
any ssh sessions in awhile - something they have in common with the evening test
runs.

I recently downgraded my kernel to 2.2.16 with the 2.4.0-test1 USB support
backpatch applied since your 2.2.17 kernel's USB support seems to be crashing my
kernel.  The timing seems to be the same.

I am using OpenSSH 2.3.0p1-4.

Comment 2 Derek Price 2001-03-02 16:22:15 UTC

/var/log/messages from last night also confirms that the error case lacked the
error message.  Successful runs still seem to consistantly produce the error
message on session close.

I can say that at least one ssh run that used '-n' but assumed the domain name
of the host worked fine after no ssh sessions had been opened in hours.  It was
a significantly longer run than my test case (several hours), and was still
running 1.5 hours later when the next (shorter) ssh run failed.  Maybe the
length of the run is related?  The short test case is the one that has failed as
part of the long one three nights in a row.  Of course, I don't parse the output
of the sucessful command directly, only it's log files, so I might not notice a
similar discrepancy.  Then again, the error message was present when the long
session close and not for the (failed) short session.

I will try my test command once an hour or so for awhile and let you know what I
discover.

Comment 3 Pekka Savola 2001-05-11 20:48:40 UTC

This should no longer happen if you upgrade to OpenSSH 2.5.2p2 in Errata.

Comment 4 Derek Price 2002-07-11 13:43:33 UTC

This hasn't happened since I upgraded as requested and this bug could probably
be closed.