Description of problem: Having multiple mounted filesystem(s) under same key causes automount not to unmount them automatically. For instance, this entry in auto.misc: stor -rw,soft,intr,nodev,nosuid stor:/archive mounts stor:/archive at /misc/stor, and unmounts correctly when expired, but this other one: stor -rw,soft,intr,nodev,nosuid /archive stor:/archive mounts stor:/archive at /misc/stor/archive but never unmounts when expired, and automount reports the following: automount[23256]: 1 remaining in /misc Version-Release number of selected component (if applicable): # rpm -qa | grep autofs autofs-5.0.7-13.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. configure automatic mounts under the same key ( one is just enough ) 2. force the configured filesystem to be mounted 3. wait for it to be unmounted. Actual results: The configured filesystem never umounts Expected results: It should umount when time expires Additional info:
(In reply to A. Rodriguez from comment #0) > Description of problem: > > Having multiple mounted filesystem(s) under same key causes automount not to > unmount them automatically. OK, I'll see if I can reproduce this. Ian
(In reply to Ian Kent from comment #1) > (In reply to A. Rodriguez from comment #0) > > Description of problem: > > > > Having multiple mounted filesystem(s) under same key causes automount not to > > unmount them automatically. > > OK, I'll see if I can reproduce this. There must be something more going because I'm not able to duplicate this using the steps you have provided. Do you have any services or programs that periodically do some sort of checking of file systems? In particular at a frequency shorter than the expire timeout. Any access at all will reset the expire timeout. Ian
It seems that a previously badly unmounted filesystem left an entry in /etc/mtab pointing to /misc/stor which did not show up in df. After a reboot everything seems to be working fine regarding the nfs mounted systems. However I am having trouble again with the following entry in auto.misc: svma \ -fstype=fuse,port=22,rw,nodev,nosuid,nonempty,noatime,allow_other,max_read=65536 \ /dira :sshfs\#root@svma\:/mnt/dira/ \ /dirb :sshfs\#root@svma\:/mnt/dirb/ the directories are mounting fine but they never expire. Same as above. localhost automount[8299]: 2 remaining in /misc Could you please check this configuration ?
(In reply to Ian Kent from comment #2) > There must be something more going because I'm not able to > duplicate this using the steps you have provided. > > Do you have any services or programs that periodically do > some sort of checking of file systems? > > In particular at a frequency shorter than the expire timeout. > Any access at all will reset the expire timeout. > > Ian Again experiencing problems with this configuration. I have checked with lsof and no process is using the directory except automount. There are no services or programs that are accesing that filesystem periodically. Also I have shortened the timeout to 4 sec and the directory is not automatically unmounted. Here hare some configuration parameters: cat /etc/sysconfig/autofs | grep -v "#" TIMEOUT=4 BROWSE_MODE="no" MOUNT_NFS_DEFAULT_PROTOCOL=4 LOGGING="debug" USE_MISC_DEVICE="yes" and here is some debugging output: Jun 26 01:46:22 localhost automount[15994]: umount_multi: path /misc/stor/archive incl 1 Jun 26 01:46:22 localhost automount[15994]: umount_subtree_mounts: unmounting dir = /misc/stor/archive Jun 26 01:46:22 localhost automount[15994]: spawn_umount: mtab link detected, passing -n to mount Jun 26 01:46:22 localhost automount[15994]: expired /misc/stor/archive Jun 26 01:46:22 localhost automount[15994]: dev_ioctl_send_ready: token = 5472 Jun 26 01:46:22 localhost automount[15994]: expire_cleanup: got thid 139904722872064 path /misc stat 2 Jun 26 01:46:22 localhost automount[15994]: expire_cleanup: sigchld: exp 139904722872064 finished, switching from 2 to 1 Jun 26 01:46:22 localhost automount[15994]: st_ready: st_ready(): state = 2 path /misc Jun 26 01:46:23 localhost automount[15994]: handle_packet: type = 5 Jun 26 01:46:23 localhost automount[15994]: handle_packet_missing_direct: token 5473, name /misc/stor/archive, request pid 8719 Jun 26 01:46:23 localhost automount[15994]: attempting to mount entry /misc/stor/archive Jun 26 01:46:23 localhost automount[15994]: lookup_mount: lookup(file): looking up /misc/stor/archive Jun 26 01:46:23 localhost automount[15994]: lookup_mount: lookup(file): /misc/stor/archive -> -rw,soft,intr,nodev,nosuid stor:/archive Jun 26 01:46:23 localhost automount[15994]: parse_mount: parse(sun): expanded entry: -rw,soft,intr,nodev,nosuid stor:/archive Jun 26 01:46:23 localhost automount[15994]: parse_mount: parse(sun): gathered options: rw,soft,intr,nodev,nosuid Jun 26 01:46:23 localhost automount[15994]: sun_mount: parse(sun): mounting root /misc/stor/archive, mountpoint /misc/stor/archive, what stor:/archive, fstype nfs, options rw,soft,intr,nodev,nosuid Jun 26 01:46:23 localhost automount[15994]: mount_mount: mount(nfs): root=/misc/stor/archive name=/misc/stor/archive what=stor:/archive, fstype=nfs, options=rw,soft,intr,nodev,nosuid Jun 26 01:46:23 localhost automount[15994]: mount_mount: mount(nfs): nfs options="rw,soft,intr,nodev,nosuid", nobind=0, nosymlink=0, ro=0 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: called with host stor(XXX.XXX.XXX.XXX) proto 6 version 0x70 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: nfs v4 rpc ping time: 0.000376 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: nfs v3 rpc ping time: 0.000376 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: host stor cost 376 weight 0 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: called with host stor(XXX.XXX.XXX.XXX) proto 17 version 0x70 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: nfs v4 rpc ping time: 0.000247 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: nfs v3 rpc ping time: 0.000390 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: nfs v2 rpc ping time: 0.000408 Jun 26 01:46:23 localhost automount[15994]: get_nfs_info: host stor cost 348 weight 0 Jun 26 01:46:23 localhost automount[15994]: prune_host_list: selected subset of hosts that support NFS4 over TCP Jun 26 01:46:23 localhost automount[15994]: mount_mount: mount(nfs): calling mkdir_path /misc/stor/archive Jun 26 01:46:23 localhost automount[15994]: mount_mount: mount(nfs): calling mount -t nfs -s -o rw,soft,intr,nodev,nosuid stor:/archive /misc/stor/archive Jun 26 01:46:23 localhost automount[15994]: spawn_mount: mtab link detected, passing -n to mount Jun 26 01:46:23 localhost automount[15994]: mount_mount: mount(nfs): mounted stor:/archive on /misc/stor/archive Jun 26 01:46:23 localhost automount[15994]: dev_ioctl_send_ready: token = 5473 Jun 26 01:46:23 localhost automount[15994]: mounted /misc/stor/archive Jun 26 01:46:23 localhost automount[15994]: st_expire: state 1 path /net It seems that the path /misc/stor/archive expires at 4 sec, but it gets somehow remounted.
(In reply to A. Rodriguez from comment #4) > > It seems that the path /misc/stor/archive expires at 4 sec, but it gets > somehow remounted. Right, so something is triggering a mount. The kernel is duty bound to call back to the automount daemon upon access attempts like this. I suspect it is one of the gvfs or related processes doing aggressive mount/umount monitoring. I don't know why these folks keep on making what I consider to be a mistake over and over again. You can get the pid of the process that is causing the remount from the debug log you are taking. Sometimes it isn't easy to locate the process causing it because they sometimes do this in a sub-process which has gone by the time you get to look but one way or another you need to work out what is doing it. Once you do identify which package is doing it you can follow up with the maintainer.
(In reply to Ian Kent from comment #5) > Right, so something is triggering a mount. > The kernel is duty bound to call back to the automount daemon > upon access attempts like this. > > I suspect it is one of the gvfs or related processes doing > aggressive mount/umount monitoring. > > I don't know why these folks keep on making what I consider > to be a mistake over and over again. > > You can get the pid of the process that is causing the > remount from the debug log you are taking. Sometimes it > isn't easy to locate the process causing it because they > sometimes do this in a sub-process which has gone by the > time you get to look but one way or another you need to > work out what is doing it. > > Once you do identify which package is doing it you can > follow up with the maintainer. Ok you were right on the money!. Here is the culprit: # ps ax | grep 8719 8719 ? S 0:51 ksysguardd from comment 4: handle_packet_missing_direct: token 5473, name /misc/stor/archive, request pid 8719 <------ I am using bubblemon to monitor cpu usage and that applet starts ksysguardd. To overcome this one could set the sampling time of bubblemon > TIMEOUT of autofs, or remove DiskStat from Sensors list in /etc/ksysguardd.conf. Meanwhile I have filed a bug regarding ksysguardd (https://bugzilla.redhat.com/show_bug.cgi?id=978431). Cheers!