Bug 161446 - uninterruptible sleep processes when copying from file-roller to nautilus
Summary: uninterruptible sleep processes when copying from file-roller to nautilus
Status: CLOSED DUPLICATE of bug 184549
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils   
(Show other bugs)
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-23 14:35 UTC by Marty Wesley
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-12 14:01:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Marty Wesley 2005-06-23 14:35:24 UTC
+++ This bug was initially created as a clone of Bug #155021 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323
Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
An up to date Fedora Core 3 machine mounts my home directory from a
NFSv4-server. When "draging and drop"-copying 100 files at the same time from a
file /tmp/r/a.tar.gz opened in file-roller to a nfs-directory ~/nfscrash10
opened in nautilus, the copying stops after about half of the files showing a
pop-up window with a progress bar.

windows title:

"Copying files."

window content:

"Files copied: 43 of 100
Copying: a47
From: /tmp/fr-XzJiHU/a
To: /nfs/home/others/esjolund/nfscrash10
and there is a cancel push-button.

Pressing cancel just makes the window not being repainted.
Any process accesing my nfs home directory hangs from now on. For instance
typing "ls ~" on the command line will just leave the ls-process hanging.

Executing the command "ps auxw", I found out that many of the processes with my
uid are in the "D"-state ( uninterruptible sleep ).

The only way to get out of the situation tend to be to reboot the machine.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. login with kde
2. on the command line type: 
   mkdir ~/nfscrash10
3. on the command line type:
   nautilus ~/nfscrash10
4. on the command line type:
   file-roller /tmp/r/a.tar.gz 
  You now see that file-roller expands the a.tar.gz file. File-roller
  will show you the directory "a" which resides in a.tar.gz.
5. open the directory "a" in file-roller. Now the 100 files from a.tar.gz is
visible in file-roller.
6. ctrl-a (select all)
7. press left mouse button and drag the files to the nautilus window.
8. release left mouse button
   A pop up window shows you the progress of the copying. After copying about 
   half of the files, the copying seems to stop. 
9. Because nothing seems to happen I press cancel in the pop up window.

Actual Results:  Processes accessing nfs home directory now hangs. Some
processes are in the 
"D" running state ( uninterruptible sleep ).

Expected Results:  Processes should not hang.

Additional info:

Oxygen is the hostname of my machine ( the nfs client ).

[esjolund@oxygen ~]$ grep nfs /etc/auto.nfs
home  -rw,fstype=nfs4,hard,intr,nosuid,tcp  nfs.sbc.su.se:/home

[esjolund@oxygen ~]$ uname -a
Linux oxygen 2.6.11-1.14_FC3 #1 Thu Apr 7 19:23:49 EDT 2005 i686 i686 i386 GNU/Linux

I also did 

echo t > /proc/sysrq-trigger

The resulting log from /var/log/messages will be attached to the bug report.

Comment 3 Steve Dickson 2005-07-27 12:20:13 UTC
It appears we are not recovering from NFS4ERR_DELAY errors.
This will need more investigation...

PID: 10093  TASK: f3695110  CPU: 0   COMMAND: "nautilus"
 #0 [f5ebad44] schedule at c02e2fcd
 #1 [f5ebada0] schedule_timeout at c02e3bfa
 #2 [f5ebaddc] nfs4_delay at f8b781b4
 #3 [f5ebadf8] nfs4_handle_exception at f8b782a7
 #4 [f5ebae04] nfs4_do_setattr at f8b7609d
 #5 [f5ebae20] nfs4_proc_setattr at f8b768f3
 #6 [f5ebae48] nfs_setattr at f8b67f1a
 #7 [f5ebaef0] notify_change at c0173b9c
 #8 [f5ebaf10] chown_common at c015adf0
 #9 [f5ebaf64] sys_chown at c015ae48
#10 [f5ebafc0] system_call at c02e5554

Comment 9 RHEL Product and Program Management 2006-08-18 17:37:56 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 10 Steve Dickson 2006-09-12 14:01:08 UTC

*** This bug has been marked as a duplicate of 184549 ***

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