Bug 112336 - ftp hangs (never completes)
Summary: ftp hangs (never completes)
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: s390x Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-17 22:22 UTC by Betsie Spann
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:32:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
trace on host who owns the file; text mode (18.96 KB, text/plain)
2004-01-08 21:18 UTC, Betsie Spann
no flags Details
trace on host attempting to ftp the file D1.tar (18.40 KB, text/plain)
2004-01-08 21:19 UTC, Betsie Spann
no flags Details
sysrq-trigger on client when hung on ftp receive (58.78 KB, text/plain)
2004-01-09 19:17 UTC, Betsie Spann
no flags Details
client tcpip trace (21.45 KB, text/plain)
2004-01-14 22:30 UTC, Betsie Spann
no flags Details
NT host doing a get from this RH 3.0 Linux (19.15 KB, text/plain)
2004-01-15 23:17 UTC, Betsie Spann
no flags Details
Linux host doing a put to a Intel Linux host (50.34 KB, text/plain)
2004-01-15 23:18 UTC, Betsie Spann
no flags Details

Description Betsie Spann 2003-12-17 22:22:00 UTC
Description of problem:
ftp of large tar file to a logical volume hangs (never completes). 
Same tar file can be ftped to a device that is not part of lvm.

Version-Release number of selected component (if applicable):
AS3.0 platform is s390x.
z/VM 4.0 on an IBM 990 zSeries

How reproducible:
any time

Steps to Reproduce:
1. ftp from one VM guest to second VM guest
2. from directory is /dev/dasdf1
3. to directory is /dev/VGtest/testvol  
Actual results:
never completes.  must reboot target system

Expected results:
successful transfer of tar file

Additional info:

Comment 1 Stephen Tweedie 2003-12-18 16:22:03 UTC
Could you provide a stack backtrace for the offending task, please?  A
system-wide trace can be obtained with sysrq-t.

Comment 2 Betsie Spann 2004-01-06 22:20:16 UTC
How can I do this on an S/390 guest?  I get "command not found" for 
sysrq and sysrq-t.

Comment 3 Stephen Tweedie 2004-01-08 00:02:56 UTC
"echo -n t > /proc/sysrq-trigger" should do it, thanks.

Comment 4 Betsie Spann 2004-01-08 20:00:00 UTC
I have a VM system console for the host that the ftp file was being 
pulled from, i.e. the originating host.  It contains the output from 
the echo command.  I did a control c and closed the ftp session from 
the second host and then did the same echo command there.  I have the 
VM system console file from the second host.
Where do I send the system console files? 

Comment 5 Stephen Tweedie 2004-01-08 20:57:34 UTC
Please attach them into bugzilla: there should be a button at the
bottom of the bug report for "create a new attachment."  Thanks!

Comment 6 Betsie Spann 2004-01-08 21:18:40 UTC
Created attachment 96839 [details]
trace on host who owns the file; text mode

Comment 7 Betsie Spann 2004-01-08 21:19:50 UTC
Created attachment 96840 [details]
trace on host attempting to ftp the file D1.tar

Comment 8 Stephen Tweedie 2004-01-08 22:21:30 UTC
Well, on the ftp host all the vsftp daemons are in S mode in the
networking stack.  There's no sign at all of any LVM activity in
there.    Likewise on the host doing the ftp client.

And the ftp command exited normally according to the log: I don't
understand where the "must reboot target system" comes from.

Looks like you need an "strace" of the ftp client and server to go
much further, but on the face of it the traces here don't show any
sign of an LVM-specific problem.

Comment 9 Betsie Spann 2004-01-09 19:16:36 UTC
I ran the same ftp test to a non-LVM disk several times. At this 
point, LVM doesn't seem to be involved.  The first receive of a file 
is successful. The second receive seems to hang at about the half-way 
mark.  All sessions are hung. No activity on the guest can be seen by 
the VM IND command.  I abort the ftp on the client with a control c 
on the 3270 console (symbol above the numeric 6 followed by c). All 
sessions recover.  Target disk is 2G and at 48% at this time.

Comment 10 Betsie Spann 2004-01-09 19:17:41 UTC
Created attachment 96865 [details]
sysrq-trigger on client when hung on ftp receive

Comment 11 Pete Zaitcev 2004-01-14 19:43:45 UTC
Very nice trace, but the ^C was entered before the Sysrq-T.
We need the Sysrq-T to capture the hanging process.

Betsie, please do this:
 - Before running the ftp, do "echo 8 > /proc/sys/kernel/printk"
   to raise the log level, do "echo 1 > /proc/sys/kernel/sysrq"
   to enable sysrq from console.
 - Run ftp (make sure that it hangs, e.g. wait a little)
 - Enter  ^-t  off the start of the line, just like ^c

This time, a stack of the ftp should be captured.

Comment 12 Betsie Spann 2004-01-14 22:30:59 UTC
Created attachment 96997 [details]
client tcpip trace

Thank you for the instructions.  Trace taken on client.

Comment 13 Pete Zaitcev 2004-01-15 00:35:50 UTC
Everything came out ok, but I'm still confused. The ftp just
sleeps while reading from a socket. More thinking is needed.

Comment 14 Betsie Spann 2004-01-15 23:17:44 UTC
Created attachment 97045 [details]
NT host doing a get from this RH 3.0 Linux

Trace taken on Linux host when an NT machine was doing a get of a large tar

Comment 15 Betsie Spann 2004-01-15 23:18:43 UTC
Created attachment 97046 [details]
Linux host doing a put to a Intel Linux host

Tried to put the large tar file on an Intel Linux host.

Comment 16 Pete Zaitcev 2005-05-13 17:59:37 UTC
Is this still a problem? I suspect it should be the case, because there
were no radical changes to RHEL 3. But is a test case still available?

Comment 17 RHEL Product and Program Management 2007-10-19 19:32:10 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.