On Thu, 2012-08-23 at 17:43 +0200, Karel Zak 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 :-) > > BTW, why do you care about the exit code? Should be enough that > umount failed (exit code is non zero) ? Because of the problems that used to result when mtab got out of sync. When mtab wasn't updated calling mount again would fix that and that's what autofs does. The other case is that autofs needs to return success if the error is only that the mtab hasn't been updated because a sensibly configured autofs is independent of the text based mtab. If mtab is symlinked this error return shouldn't ever be returned. > > > > == 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 > > 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 guess that Ian and all users will be happy if all mount stuff will > use the same exit codes :-) > > Karel > -- 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
