Description of problem: I have nfs server (currently fc6) where I have following exports (example): /home/share1 /opt/share2 /opt/share3 /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): psmisc-22.3-2.fc7 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: Always. Steps to Reproduce: 1. Mount two different nfs shares from the nfs server which reside on the same filesystem. 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:
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.
I have prepared a patch and send it to the upstream maintainer. Let's see what he thinks.
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.
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?
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.
Even psmisc-22.3-3.1.fc7 does not solve the problem.
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=10.34.33.165) dhcp-lab-165:/srv/exports/export2 on /mnt/mount2 type nfs (rw,addr=10.34.33.165) [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 psmisc-22.3-3.1.fc7 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.
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).
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.
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.