On Thu, Aug 23, 2012 at 12:43 PM, Karel Zak <kzak@xxxxxxxxxx> wrote: > On Wed, Aug 22, 2012 at 01:00:00PM +0800, Ian Kent wrote: >> On Tue, 2012-08-21 at 18:56 -0300, Leonardo Chiquitto wrote: >> > When I was investigating the "recovery of busy mounts" problem, I >> > discovered that the proposed fix was not working with some versions >> > of nfs-utils. Turns out that the issue is caused by inconsistencies >> > in the umount return codes: different versions of umount and >> > umount.nfs return different error codes when failing to unmount >> > a busy volume. Some examples: >> > >> > == nfs-client-1.2.6 (latest openSUSE), nfs-client-1.2.3 (SLES 11-SP2, RHEL6) >> > >> > /mnt # umount . >> > umount.nfs: /mnt: device is busy >> > # echo $? >> > 16 >> > >> > /mnt # umount . >> > umount.nfs4: /mnt: device is busy >> > # echo $? >> > 16 > > Yes, expected: > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=76908c3f14a12e865054ea5d6e4cad201c28839a > > We had 32 there, but for compatibility with autofs it was > reverted to 16 :-) Not really with AutoFS, but with the old versions of nfs-utils or even new versions when not configured to use libmount. > BTW, why do you care about the exit code? Should be enough that > umount failed (exit code is non zero) ? There's one corner case that AutoFS handles: when the mount/umount operation succeeds but /etc/mtab is not updated. It looks like old versions of umount (before the separation of umount and umount.nfs) returned error code 16 to indicate this case. As Ian said, this is not that important anymore because modern distributions link /etc/mtab to /proc/mounts. >> > == util-linux-2.21.2 (latest openSUSE) >> > >> > /boot # umount . >> > umount: /boot: target is busy. >> > (In some cases useful info about processes that use >> > the device is found by lsof(8) or fuser(1)) >> > /boot # echo $? >> > 32 > > This is new umount implementation where we share the exit codes with > mount(8) (as documented in mount man page). > > The old original umount(8) returns 0 on success and greater than zero > (usually 1) on error or exit code from /sbin/umount.* helpers. It > means that the original umount(8) does not match with umount.nfs too. > > Personally I believe the original umount exit codes are pretty poor. > IMHO it would be better to use something more verbose (as we already > use for mount(8)). > > I see two possible ways: > > 1) use exit codes from mount man page (32 = [u]mount failure) > everywhere including umount.nfs IMHO this is the best way to move forward. > 2) use 0 or 1 or 16 for backward compatibility. > > ... now we mix both ;-( > > Neil, Steve -- what about to modify umount.nfs to use EX_FAIL again? I owe an apology to Neil here because I reported the change in umount's return code after we started linking it against libmount as a bug :-/ > I guess that Ian and all users will be happy if all mount stuff will > use the same exit codes :-) Agreed! Thanks, Leonardo -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
