Bug 245538 - fuser incorrectly reports processess using nfs filesystems
Summary: fuser incorrectly reports processess using nfs filesystems
Alias: None
Product: Fedora
Classification: Fedora
Component: psmisc
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Smetana
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-25 09:36 UTC by Marek Greško
Modified: 2007-11-30 22:12 UTC (History)
0 users

Clone Of:
Last Closed: 2007-10-30 13:59:37 UTC

Attachments (Terms of Use)

Description Marek Greško 2007-06-25 09:36:44 UTC
Description of problem:

I have nfs server (currently fc6) where I have following exports (example):

/home and /opt are on separate filesystems.

When I mount these filesystems on a client, and run fuser on /opt/share3 it also
reports processes using /opt/share2. The /home/share1 is not affected since it
is different mount point on the server.

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

I found that when I user kernel 2.6.17 on the client, everything works
correctly. Maybe fuser does not follow some change in the kernel. Or the kernel bug?

How reproducible:

Steps to Reproduce:
1. Mount two different nfs shares from the nfs server which reside on the same
2. Run fuser -vm /opt/share3.
3. Processes using /opt/share2 but not /opt/share3 are reported.
Actual results:
Processes using /opt/share2 but not /opt/share3 are reported.

Expected results:
Processes using /opt/share2 but not /opt/share3 are not reported.

Additional info:

Comment 1 Tomas Smetana 2007-06-26 13:20:17 UTC
Running stat on the mounted directories will show that they are considered to
reside on the same device. Therefore fuser -m reports the processes correctly
(from this point of view). Looks that the device in the newer clients is
determined by the fsid reported by the server. This was different in the
previous versions and I don't like it either.

Although I'm not sure whether this can be considered a fuser bug. I'll try to
investigate the problem further.

Comment 2 Tomas Smetana 2007-08-03 09:43:35 UTC
I have prepared a patch and send it to the upstream maintainer. Let's see what
he thinks.

Comment 3 Tomas Smetana 2007-08-20 13:55:00 UTC
No response from upstream yet...  I have committed a patched version for F-7
(psmisc-22.3-3.fc7) into testing repository.  In few hours it should be
available from any of the mirrors (e.g.
ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/updates/testing/7/i386/).  Please
note  that if I don't get a positive response from the upstream or if any
regression occurs, I'll have to unpush the package and drop the patch.

Comment 4 Marek Greško 2007-08-21 13:17:43 UTC
I tried to put fuser from psmisc-22.3-3.fc7 into /usr/local/sbin and it did not
solve the problem. Isn't it sufficient to replace only fuser binary?

Comment 5 Tomas Smetana 2007-08-21 13:57:52 UTC
This patch had more problems I discovered later...   I was too hasty.  I'm
committing a less intrusive version.  Sorry for that -- 22.3-3.1 should be better.

Comment 6 Marek Greško 2007-08-30 17:20:46 UTC
Even psmisc-22.3-3.1.fc7 does not solve the problem.

Comment 7 Tomas Smetana 2007-09-03 09:46:30 UTC
Hmmm...  Here's the set of commands I used for testing:

[tsmetana@vmware187 ~]$ mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
dhcp-lab-165:/srv/exports/export1 on /mnt/mount1 type nfs (rw,addr=
dhcp-lab-165:/srv/exports/export2 on /mnt/mount2 type nfs (rw,addr=
[tsmetana@vmware187 ~]$ stat /mnt/mount1
  File: `/mnt/mount1'
  Size: 4096            Blocks: 16         IO Block: 262144 directory
Device: 16h/22d Inode: 652991      Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2007-09-03 11:32:24.000000000 +0200
Modify: 2007-08-09 11:37:24.000000000 +0200
Change: 2007-08-09 11:37:24.000000000 +0200
[tsmetana@vmware187 ~]$ stat /mnt/mount2
  File: `/mnt/mount2'
  Size: 4096            Blocks: 16         IO Block: 262144 directory
Device: 16h/22d Inode: 652992      Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2007-08-22 04:09:36.000000000 +0200
Modify: 2007-08-02 12:01:22.000000000 +0200
Change: 2007-08-02 12:01:22.000000000 +0200
[tsmetana@vmware187 ~]$ ps -o pid,cmd -u tsmetana | grep mnt
12600 tail -f /mnt/mount1/file1.txt
12651 tail -f /mnt/mount2/file2.txt
12686 grep mnt
[tsmetana@vmware187 ~]$ /sbin/fuser -vm /mnt/mount1

                     USER        PID ACCESS COMMAND
/mnt/mount1:         tsmetana  12600 f.... tail

[tsmetana@vmware187 ~]$ rpm -q psmisc

As you can see I had two processes accessing the two nfs mounts with the same
device ID but only one is reported by the fuser command.  Could you please
provide something similar so I could locate the problem more precisely?  Thank you.

Comment 8 Tomas Smetana 2007-09-20 11:53:14 UTC
I couldn't reproduce the problem with the modified package but I had to pull it
out of the testing repository and placed it to
http://fedorapeople.org/~tsmetana/ for those who want to test it.  If you
encounter the problem described in the bug, please post the nfs configuration
and any reliable information (something like comment #7).

Comment 9 Marek Greško 2007-09-20 13:16:02 UTC
Yes. Your scenario works and it is sufficient for me. I was testing it like this:

mount server:/opt/share1 /mnt/share1
mount server:/opt/share2 /mnt/share2
cd /mnt/share1
fuser -vm ../share2

Fuser was reporting bash. I think this should not happen, but it this testing
scenario is not what i really need. I need your scenario to work correctly.

Comment 10 Tomas Smetana 2007-10-30 13:59:37 UTC
Well.  The patch was sent upstream.  I got a response saying that there are more
issues with fuser and NFS that should be solved.  We might wait for future
psmisc releases.

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