On Wed, 2012-08-22 at 13:00 +0800, Ian Kent wrote:
> 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.
Umm ... that's not correct, the error returns are only documented for
mount(8), not for umount(8) ....
>
> 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
--
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
