在非活动之后，autofs不断开连接。

Question

我在多个linux服务器上安装了autofs，这些服务器为用户/home目录连接到中心NFS服务器。当在登录时挂载目录时，它工作得很好，但是挂载似乎从不超时。我已经检查了/etc/sysconfig/autofs，并且默认设置为300，所以这些设置应该在5分钟后超时。

重新启动autofs会对所有目录进行汇总，所以我知道它是有能力的。

我尝试在目录中随机使用lsof，但在任何时候都不会打开任何文件。

我还安装了一个我知道没有活动的随机目录，但是这些目录本身从来没有激活过。其中一些盒子中的10+用户已经登录一次，挂载永远不会掉下来。

我只是想找出一个更好的方法来找出原因。我在日志里没有看到任何具体的东西。

如有任何建议，敬请见谅。谢谢!

更新

我打开了对autofs的调试，但它似乎并没有显示出任何异常。这些日志是在最初挂载/home/user1 1之后7分钟和6分钟不活动之后生成的。根据5分钟的默认设置，这应该已经卸载了。我从来没见过一根圆木，上面写着有人试图到乌蒙特去。

Jan 11 12:52:00 linux automount[26505]: st_expire: state 1 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc: exp_proc = 3055176592 path /home
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user1
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user2
Jan 11 12:52:00 linux automount[26505]: expire_proc_indirect: expire /home/user3
Jan 11 12:52:00 linux automount[26505]: 3 remaining in /home
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: got thid 3055176592 path /home stat 7
Jan 11 12:52:00 linux automount[26505]: expire_cleanup: sigchld: exp 3055176592 finished, switching from 2 to 1
Jan 11 12:52:00 linux automount[26505]: st_ready: st_ready(): state = 2 path /home

在与Red支持部门讨论过这个问题后，最终的解决方案就是缩短主目录的超时值。我这么做了，看上去很好。很明显，每隔2/2到3分钟，就会有什么东西穿过坐骑点，导致它无法入睡。

解决方案是将超时值添加到该映射的/etc/auto.master文件中：

 /home     /etc/auto_home --timeout=120

Answer 1

除了超时值变量，autofs还有一个检查间隔：

# cat /var/log/messages
Jan 11 21:45:35 client automount[24804]: mounted offset on /net/server/share with timeout 300, freq 75 seconds

它等于超时值/4。每次超时/4秒，autofs都会询问内核上次访问目录的时间。因此，在您的环境中，您的目录在375秒的不活动后就会出现。

要获得更详细的日志，您应该将LOGGING="debug"添加到/etc/sysconfig/autofs

Answer 2

我今天花了几个小时试图调试和类似的问题。这是我所发现的，以及我是如何解决的。]

安装程序:我想在/mnt/ nfs / home上自动安装dir，其中包含来自nfs服务器“srv 1:/srv/home”的用户主目录。NFS服务器导出NFS4。autofs版本5.1.3

我把每一个客户都配置成这样：

/etc/auto.装入:包含以下内容的文件：

... 
/mnt/nfs /etc/auto.home
...

/etc/auto.home：

homes  -rw,soft,intr,rsize=8192,wsize=8192 srv1:/srv/homes

最终，这代表了一张间接地图。汽车坐骑就像一种魅力。我得到的NFS卷正确安装和工作。但是..。它永远不会自动卸载。尽管autofs.conf文件说：

mount显示600秒超时：

#1# /etc/auto.home on /mnt/nfs type autofs (rw,relatime,fd=18,pgrp=5054,timeout=300,minproto=5,maxproto=5,indirect) 
srv1:/srv/homes on /mnt/nfs/homes type nfs4 (rw,relatime,vers=4.2,rsize=8192,wsize=8192,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)

我在(调试日志级别激活)日志中看到了从日志was发出的与wanpelaman完全相同的autofs日志

automount[53593]: st_expire: state 1 path /mnt/nfs
automount[53593]: expire_proc: exp_proc = 139645987374848 path /mnt/nfs
automount[53593]: expire_proc_indirect: expire /mnt/nfs/homes
automount[53593]: 1 remaining in /mnt/nfs
automount[53593]: expire_cleanup: got thid 139645987374848 path /mnt/nfs stat 3
automount[53593]: expire_cleanup: sigchld: exp 139645987374848 finished, switching from 2 to 1
automount[53593]: st_ready: st_ready(): state = 2 path /mnt/nfs

当时，我放弃了autofs，决定用systemd复制automount。实际上，我运行了它，在这个时候，一切都运行得很好--自动挂载，在预定义的空闲期后自动卸载。完美无缺。但是系统..。有点笨拙(别朝我开枪，我其实挺喜欢的)。然后，我查看了systemd如何处理自动安装：

#2# systemd-1 on /mnt/nfs/homes type autofs (rw,relatime,fd=35,pgrp=1,timeout=20,minproto=5,maxproto=5,direct)
srv1:/srv/homes on /mnt/nfs/homes type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)

#1#与#2#的区别在于后者是直接映射，而#1#是间接映射。因此，我立即决定在另一个客户端上重新配置autofs，并创建这样的直接映射：

/etc/auto.master

/-   /etc/auto.home

/etc/auto.home

/mnt/nfs/homes  -rw,soft,intr,rsize=8192,wsize=8192 srv1:/srv/homes

这最终解决了这个问题。自动安装和自动安装都工作得很好。在/etc/autofs.conf中预定义的空闲时间后成功运行umount

绝对不需要对NFS服务器进行任何修改。

Answer 3

对于遇到类似问题的任何其他人，现代桌面上都会有GUI进程，它们不断地扫描驱动器。特别是Gnome上的Nautilus和KDE上的Dolphin，以及像Baloo这样的文件索引应用程序。这些都能引起症状。

对我(运行KDE)来说，自动调试日志记录的唯一线索是"1剩余“，例如：

    Feb 13 00:00:44 fig automount[19026]: expire_proc: exp_proc = 139620739028736 path /mnt/vchanger
    Feb 13 00:00:44 fig automount[19026]: expire_proc_indirect: expire /mnt/vchanger/fb207cd6-6931-4af4-8293-c82ee0d2394c
    Feb 13 00:00:44 fig automount[19026]: 1 remaining in /mnt/vchanger

这并没有真正确定来源。另外，没有一个人给出任何见解。

最后，经过淘汰过程，我确定有2份申请：

• KSysGuard (KDE系统监视器)
• 海豚(档案管理员)

在这种情况下，海豚的问题可以通过在树视图中“隐藏”违规挂载的磁盘来解决。

KSysGuard看起来并不是可配置的，但是除非您正在调试什么东西，否则让它长期运行可能是不寻常的。希望其他应用程序可以在允许排除以防止自动挂载点被扫描方面更可配置。