Created attachment 468687 [details] Patch for netfs init script Description of problem: netfs fails to umount cifs if there are bind mounts active Version-Release number of selected component (if applicable): 14 How reproducible: Always for cifs shares Steps to Reproduce: 1. add e.g. cifs share to /etc/fstab 2. mount -o bind <share> <destination> 3. shutdown Actual results: cifs vfs no response for cmd 50 Expected results: Clean unmount and network shutdown Additional info: Patch attached.
cifs-utils should handle this better; other umount programs do.
Can you explain what the problem is here and what cifs-utils should do that it's not doing now?
No response to my question within the last week. Moving this back to initscripts, though maybe it would be better suited as a util-linux bug... umount.cifs has been deprecated for some time and never shipped as part of cifs-utils. If there's something the kernel needs to do better here, then please reassign this back to me with a proper explanation and I'll have a look.
The attached patch simply reverses the order of the filesystems passed on the commandline to 'umount'; if that actually solves the issue, then the umount routines need fixed to not require this for cifs, as other filesystem types don't have this stringent ordering requirement (afaik).
cc'ing Karel Zak... No, that's not all that it does. It also circumvents the '-a' logic in /bin/umount. /bin/umount uses the contents of /etc/mtab to determine what to unmount, and I think the problem is likely there. When I do a cifs mount and then a bind mount of that, I get this in /etc/mtab: //server/scratch /mnt/cifs cifs rw 0 0 /mnt/cifs /mnt/bind none rw,bind 0 0 When I edit /etc/mtab and change that "none" to "cifs" then umount -t cifs -a works as expected. So, I don't think this is a kernel problem, or a problem with mount.cifs. It's probably a bug in util-linux-ng. /bin/mount should probably fill out the fstype field in /etc/mtab with the proper type when performing a bind mount. So, reassigning to util-linux-ng for now, unless Karel wants to make a case that it's an initscripts bug.
This is mount(8) bug. Thanks for your bug report.
It's not so simple to fix this problem in mount(8). Sorry. The "mount --bind" does not work with a real device, so the filesystem type is unknown and fill in something other than "none" to the /etc/mtab file is difficult. This problem does not exist on systems without /etc/mtab (e.g. F15). From my point of view the best way (for now) is to use David's bugfix (from the first comment). It's probably better when initscripts rely on /proc/mounts than on /etc/mtab. So, reassigning to initscripts. Note that umount does not work recursively, so it's mistake to umount only subset of mountpoint by any initscipt during system shutdown. There could be a submount, for example mount -t cifs //foo /mnt/foo mount -t ext3 /mnt/foo/subdir then "umount -a -t cifs" will return EBUSY on /mnt/foo. I'll update my upstream TODO list to address all these issues. It seems that at least findmnt(8) should be able to return all submounts for the selected directory.
Added on master and F-14 branch, may be in a future F-14 update. Thanks! http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=328e7a968515028d5668a63e6f4851a9c8c7e4a3
Package initscripts-9.20.2-1.fc14.1: * should fix your issue, * was pushed to the Fedora 14 updates-testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initscripts-9.20.2-1.fc14.1' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/initscripts-9.20.2-1.fc14.1 then log in and leave karma (feedback).
initscripts-9.20.2-1.fc14.1 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.