autofsマウントが非アクティブになっても切断されない

私が持っているのautofsユーザ/ホームディレクトリのための中央NFSサーバに接続している複数のLinuxサーバにインストールします。ログイン時にディレクトリをマウントするときにうまく機能しますが、マウントがタイムアウトすることはありません。/ 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

Update 2 これについてRed Hatサポートと話し合った後、解決策はホームディレクトリのタイムアウト値を単に短くすることでした。私はそれをし、よく見えます。どうやら何かがマウントポイントを2 1/2〜3分ごとに通過し、これが継続する原因となっています。

解決策は、そのマッピングの/etc/auto.masterファイルにタイムアウト値を追加することでした：

 /home     /etc/auto_home --timeout=120

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と同じです。TIMEOUT / 4秒ごとに、autofsは、ディレクトリが最後にアクセスされたときにカーネルに質問します。したがって、ご使用の環境では、375秒間何も操作しないとディレクトリが表示されなくなります。

追加LOGGING="debug"する必要があるより詳細なログを取得するには/etc/sysconfig/autofs

同様の問題がありました。私は10歳のRHEL 4.7 ProLiantサーバーを、クリスマス休みにCentOS 6とともに再インストールしました。最近（4月に）CentOS 7をインストールできる2つの新しいProLiantsがありました。

/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

同様の問題が発生している他の人のために、ドライブを継続的にスキャンする最新のデスクトップ上の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は構成可能ではないように見えますが、何かをデバッグしている場合を除いて、長期間実行するのはおそらく珍しいことです。うまくいけば、自動マウントマウントポイントがスキャンされないように除外を許可することで、他のアプリケーションがより構成可能になる可能性があります。

今日私はデバッグおよび同様の問題を試みるために何時間も費やしました。ここに私が見つけたものと私がそれをどのように回避したかがあります。]

セットアップ：クライアントの/ 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ファイルには次のように書かれていますが、

そしてmount600秒のタイムアウトを示しています：

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

（デバッグログレベルをアクティブにする）autofsログで、journalctlから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をあきらめて、automount構成をsystemdで複製することにしました。実際に私はそれを実行し、現時点ではすべてがうまくいきました-自動マウント、事前定義されたアイドル期間後の自動アンマウント。完璧。しかしsystemd ...少し不器用です（私を撃たないでください、私は実際にそれが好きです）。次に、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

そして、これは最終的に問題を解決しました。自動マウントと自動アンマウントの両方が正常に機能しました。umountは、/ etc / autofs.confで事前定義されたアイドル時間の後に正常に実行されました

絶対にNFSサーバーの変更は必要ありませんでした。