不活动后autofs挂载不会断开


10

我在几个Linux服务器上安装了autofs,这些服务器正在连接到用户/ home目录的中央NFS服务器。在登录时挂载目录时,它的工作效果很好,但挂载似乎从未超时。我已经检查了/ etc / sysconfig / autofs,并且默认确实设置为300,所以这些应该在5分钟后超时。

重新启动autofs不会卸载所有目录,因此我知道它可以。

我尝试在目录上随机使用lsof,但是任何时候都没有打开文件。

我还安装了一个我不知道它处于活动状态的随机目录,但是这些目录从未卸载自己。其中一些服务器有10个以上的用户登录一次,而且安装数量从未下降。

我只是想找出一种更好的方法来找出原因。我在任何日志中都没有看到任何特定的内容。

任何建议表示赞赏。谢谢!

更新

我打开了对autofs的调试,但似乎并没有发现任何异常。这些日志是在最初安装/ home / user1 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

更新2 在与Red Hat支持人员讨论此事之后,解决方案最终只是缩短主目录的超时值。我做到了,看起来不错。每隔2 1/2到3分钟就会有遍历挂载点的事情,并导致这种情况持续下去。

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

 /home     /etc/auto_home --timeout=120

您使用什么命令来确定这些安装架存在?我假设df,但只想澄清一下。
Banjer 2013年

是的,我正在使用df检查安装空间。我只是以根用户身份将目录CD挂载到目录中。
SteveHNH 2013年

Answers:


4

除了TIMEOUT变量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

它等于TIMEOUT / 4。autofs每隔TIME / 4秒会询问内核上次访问目录的时间。因此,在您的环境中,闲置375秒后,目录已被删除。

要获取更详细的日志,您应该添加LOGGING="debug"/etc/sysconfig/autofs


我懂了。感谢您的澄清。闲置6分钟后,以上记录继续进行,并且超过375秒。我一直认为必须要访问这些目录,否则将尝试执行umount。我想我的真正目的是找出正在访问此目录的内容(如果有的话)。这可能是我能想到的唯一原因。
SteveHNH 2013年

1

我有一个类似的问题。在圣诞节休息期间,我用CentOS 6重新安装了10年的RHEL 4.7 ProLiant服务器。我有2个较新的ProLiant,可以在最近(4月)安装CentOS 7。

我使用/etc/auto.masterCentOS 7服务器上的一行配置从CentOS 6服务器自动挂载主目录,如下所示:

/home   /etc/auto.home

然后,我/etc/auto.home首先在CentOS 7服务器上用一行创建了一个新文件:

*      sam:/home/&

但是主目录不会卸载。我还发现主目录中的某些文件所有权最终会不时带有巨大的UID和GID号。几分钟后它将改变。

我将日志记录级别设置为“调试”,/etc/autofs.conf并开始观看journalctl -fu autofs.service。我看到了几乎相同的消息,如上所示,其中似乎没有任何线索。

由于我还没有能够理解NFS 4,我知道我们的CentOS 6服务器在默认情况下,出口其股票作为NFS 4,我尝试添加nfsvers=3/etc/auto.home像这样的文件:

training      -nfsvers=3,noac,soft,intr  sam:/home/training

我还看到了有关尝试挂载目录之类的奇怪消息/home/lib,因此在单独的行上添加了各个主目录。(这时可能应该尝试直接安装,或者尝试使用systemd自动安装。)

现在,我开始看到如下消息:

Apr 27 09:32:28 betty automount[13501]: expire_proc_indirect: expire /home/fred
Apr 27 09:32:28 betty automount[13501]: handle_packet: type = 4
Apr 27 09:32:28 betty automount[13501]: handle_packet_expire_indirect: token 21, name fred
Apr 27 09:32:28 betty automount[13501]: expiring path /home/fred
Apr 27 09:32:28 betty automount[13501]: umount_multi: path /home/fred incl 1
Apr 27 09:32:28 betty automount[13501]: umount_subtree_mounts: unmounting dir = /home/fred
Apr 27 09:32:28 betty automount[13501]: spawn_umount: mtab link detected, passing -n to mount
Apr 27 09:32:29 betty automount[13501]: rm_unwanted_fn: removing directory /home/fred
Apr 27 09:32:29 betty automount[13501]: expired /home/fred
Apr 27 09:32:29 betty automount[13501]: dev_ioctl_send_ready: token = 21
Apr 27 09:32:29 betty automount[13501]: handle_packet: type = 4
Apr 27 09:32:29 betty automount[13501]: handle_packet_expire_indirect: token 22, name barney
Apr 27 09:32:29 betty automount[13501]: expiring path /home/barney
Apr 27 09:32:29 betty automount[13501]: umount_multi: path /home/barney incl 1
Apr 27 09:32:29 betty automount[13501]: umount_subtree_mounts: unmounting dir = /home/barney
Apr 27 09:32:29 betty automount[13501]: spawn_umount: mtab link detected, passing -n to mount
Apr 27 09:32:29 betty automount[13501]: rm_unwanted_fn: removing directory /home/barney
Apr 27 09:32:29 betty automount[13501]: expired /home/barney
Apr 27 09:32:29 betty automount[13501]: dev_ioctl_send_ready: token = 22
Apr 27 09:32:29 betty automount[13501]: expire_proc_indirect: expire /home/barney
Apr 27 09:32:29 betty automount[13501]: expire_proc_indirect: expire /home/wilma
Apr 27 09:32:29 betty automount[13501]: 1 remaining in /home

现在,主目录会在10分钟后像预期的那样开始卸载-因此,在我的情况下,这是配置错误的NFS 4的问题。

重要提示:重新配置地图后,只是有效果systemctl daemon-reload还是systemctl reload autofs没有效果。我必须做systemctl restart autofs


1

对于遇到类似问题的其他任何人,现代台式机上都有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

这并没有真正确定来源。同样,lsof,fuser和auditctl(auditd)也没有提供任何见解。

最终,通过淘汰过程,我确定了2项申请:

  • KSysGuard(KDE系统监视器)
  • 海豚(文件管理器)

在这种情况下,可以通过在树状视图中“隐藏”有问题的已安装磁盘来解决Dolphin的问题。

KSysGuard似乎不是可配置的,但是除非您正在调试某些东西,否则使其长期运行可能是不寻常的。希望其他应用程序在允许排除以防止扫描自动安装安装点时可能更具可配置性。


仅供参考,如果您在编辑帖子之前登录,则以后无需批准(或等待其他人批准)。
G-Man说“恢复莫妮卡”

0

我今天花了几个小时尝试调试和类似的问题。这是我找到的内容以及如何解决的。]

设置:我想从客户端上的/ mnt / nfs / homes的nfs服务器“ srv1:/ srv / homes”自动挂载包含用户家庭目录的目录。NFS服务器导出NFS4。autofs版本5.1.3

我已经像这样配置了每个客户端:

/etc/auto.mount:包含以下内容的文件:

... 
/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)

我看到来自journalctl的(调试日志级别激活)autofs日志与wanpelaman完全一样

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服务器上进行任何修改。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.