autofs behaviour on HUP signal : deleted mounts still honored ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I'm using Centos 6.3 and the provided autofs 5.0.5.

$ uname -r
2.6.32-220.4.1.el6.x86_64
$ automount -V
Linux automount version 5.0.5-54.el6

Directories:
        config dir:     /etc/sysconfig
        maps dir:       /etc
        modules dir:    /usr/lib64/autofs

Compile options:
  DISABLE_MOUNT_LOCKING ENABLE_IGNORE_BUSY_MOUNTS WITH_HESIOD WITH_LDAP
  WITH_SASL LIBXML2_WORKAROUND WITH_LIBTIRPC


I've got a mount with a direct map that works well : I go to directory
and the automount occurs. After the timeout, it is unmounted.

If I remove this mount from the direct map, reload autofs while the
mount is not active (via kill -HUP), and try to access the mountpoint
then the mountpoint is empty : not automount occurs. So far so good.

But if I remove the mount from the direct map, reload autofs while the
mount is still active (important), wait for the timeout to occurs (the
unmount occurs) and try to access the mountpoint again, then the mount
occurs although there is no entry in the direct map and autofs has been
reloaded. From what I see, the new "empty" direct map is not honored.

Please see the steps to reproduce on a machine with a local nfs server
after the message.

Is this a wanted behaviour ? Is there any workaround ? If this is not
wanted behaviour and a known bug, I didn't find it before posting, sorry.

Regards,

Jean-Baptiste

--------------------------
Steps to reproduce :

$ # install necessary package to be a nfs server
$ echo "/usr/local/share 127.0.0.1(ro,no_root_squash,no_subtree_check)"
| sudo tee -a /etc/exports
$ sudo exportfs -a
$ sudo mkdir /tmp/mount
$ sudo mount -o vers=3 127.0.0.1:/usr/local/share /tmp/mount
$ # check that the mount is ok
$ sudo umount /tmp/mount

Use this auto.* files :

$ cat /etc/auto.master
/-      /etc/auto.mounts       --ghost --timeout=20
$ cat /etc/auto.mounts
/tmp/mount    -fstype=nfs,ro,defaults,nfsvers=3 127.0.0.1:/usr/local/share

Restart autofs :
$ sudo service autofs restart

Check that the mount is ok :
$ cd ~/
$ ls /tmp/mount
applications  info  man
$ mount
...
127.0.0.1:/usr/local/share on /tmp/mount type nfs
(ro,nfsvers=3,sloppy,addr=127.0.0.1)
...

We check that the mount is gone after the 20 seconds, perfect.
$ mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext3 (rw)
/dev/sda5 on /tmp type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

First test :
- go again to /tmp/mount to check that the mount is ok
- remove the /tmp/mount entry from auto.mounts
- go to ~/ and wait 20 seconds for /tmp/mount to unmount
- reload autofs via "service autofs reload"
- go to /tmp/mount : no automount occurs

Second test :
- Put again the /tmp/mount entry in auto.mounts
- restart autofs via "service autofs restart"

We are in a clean state. Now :

- go to /tmp/mount : automount occurs
- remove the /tmp/mount entry from auto.mounts
- reload autofs via "service autofs reload" (while the mount is still
present ! important !)
- go to ~/ and wait 20 seconds for /tmp/mount to unmount (check with the
mount command)
- go to /tmp/mount : automount OCCURS AGAIN although there is no entry
in the direct map and autofs has been reloaded






--
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


[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux