On Tue, 2012-08-21 at 18:56 -0300, Leonardo Chiquitto wrote:
> Hello,
>
> 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
>
> == 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
>
> == util-linux-2.12r or 2.13 (SLES 10-SP4, RHEL5)
>
> /mnt # umount .
> umount: /mnt: device is busy
> umount: /mnt: device is busy
> n65:/mnt # echo $?
> 1
>
> AutoFS interprets return code '16' as MTAB_NOTUPDATED (the volume
> was unmounted but /etc/mtab was not updated accordingly), and it
> seems this used to work with older versions of umount/umount.nfs.
> With newer versions it causes trouble because spawn_umount()
> will consider ret code 16 as not fatal, and return success:
>
> 626 /* This is not a fatal error */
> 627 if (ret == MTAB_NOTUPDATED) {
> 628 warn(logopt, "Unable to update the mtab file, /proc/mounts "
> 629 "and /etc/mtab will differ");
> 630 ret = 0;
> 631 }
>
> The real problem is in nfs-utils and util-linux (which should eventually
> agree on the return codes), however now we have all these versions
> on the wild and AutoFS might fail with some of them.
>
> For now, I'm using the following patch here to avoid accepting EBUSY
> as non-fatal:
>
> diff --git a/daemon/spawn.c b/daemon/spawn.c
> index 3b4a009..cd1193d 100644
> --- a/daemon/spawn.c
> +++ b/daemon/spawn.c
> @@ -623,11 +623,9 @@ int spawn_umount(unsigned logopt, ...)
> }
> }
>
> - /* This is not a fatal error */
> if (ret == MTAB_NOTUPDATED) {
> warn(logopt, "Unable to update the mtab file, /proc/mounts "
> "and /etc/mtab will differ");
> - ret = 0;
> }
>
> return ret;
>
> Ian, do you think AutoFS should adapt to the new return codes or
> should I start reporting these problems to util-linux/libmount/nfs-utils
> maintainers?
I've cc'ed Steve Dickson and Karel Zak, maybe they have some thoughts on
this too.
Since the return codes are listed in mount(8) and not listed in
mount.nfs(8), mount.nfs probably should follow the documented codes.
But that's not quite as straight forward as it sounds since, for
example, recent Fedora symlinks /etc/mtab to /proc/mounts so the mtab
locking code should never be returned.
>
> 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
--
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
