Bug 497303 - fuser -m <dev> doesn't work after lazy unmount
Summary: fuser -m <dev> doesn't work after lazy unmount
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: psmisc
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Novotny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 484835
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-23 10:09 UTC by Kari Hautio
Modified: 2009-04-23 10:54 UTC (History)
4 users (show)

Fixed In Version:
Clone Of: 484835
Environment:
Last Closed: 2009-04-23 10:54:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kari Hautio 2009-04-23 10:09:56 UTC
+++ This bug was initially created as a clone of Bug #484835 +++

Description of problem:
fuser -m <device> fails to detect open files on a filesystem that has been lazily unmounted.
This is bad since a typical use case for "fuser -m" is to kill remaining users of a filesystem.

How reproducible:
always

Steps to Reproduce:
dd if=/dev/zero of=fs.img bs=1M count=100
losetup /dev/loop4 fs.img
mkfs.ext2 /dev/loop4
mkdir mnt
mount /dev/loop4 mnt
touch mnt/testfile
less mnt/testfile
<CTRL>-Z
# these will work and display PID of less
fuser -m mnt
fuser -m /dev/loop4
# lazy umount!! as there's open file it's actually still mounted and
already open files can be accessed
umount -l mnt
fuser -m /dev/loop4
# doesn't find anything!!

Actual results:
two first fuser runs report the pid last does not

Expected results:
fuser reports the pid in all cases

Additional info:
Bug has been already reported to upstream including a patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=2545632&group_id=15273&atid=115273

--- Additional comment from pm-rhel on 2009-02-10 03:42:20 EDT ---

This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

--- Additional comment from dnovotny on 2009-02-10 06:21:22 EDT ---

Created an attachment (id=331413)
the patch from the upstream applies cleanly and I tested it works on rhel5

--- Additional comment from rdassen on 2009-02-10 06:51:53 EDT ---

Daniel, could you (or Tomas) add a note to that affect to the upstream defect
report then please? 

The upstream report was filed by the customer directly; having a public ack
from your side is likely to increase the chances of it quickly being
reviewed/accepted upstream.

--- Additional comment from dnovotny on 2009-02-10 07:08:48 EDT ---

OK, added a note to the upstream bug tracker

--- Additional comment from dnovotny on 2009-04-14 09:28:36 EDT ---

fixed in psmisc-22.2-7

--- Additional comment from errata-xmlrpc on 2009-04-22 08:44:22 EDT ---

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0439.html

Comment 1 Daniel Novotny 2009-04-23 10:54:56 UTC
fixed in psmisc-22.6-10.fc12


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