web-dev-qa-db-ja.com

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

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

pdate 2これについてRed Hatサポートに連絡した後、解決策はホームディレクトリのタイムアウト値を短くすることでした。私はそれをし、よく見えます。どうやら何かがマウントポイントを2 1/2〜3分おきに通過し、これを維持しているようです。

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

 /home     /etc/auto_home --timeout=120
rhelmountnfsautofs
10
SteveHNH

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

CentOS 7サーバーの/etc/auto.masterの行を使用して、CentOS 6サーバーからホームディレクトリを自動マウントするように構成しました。

/home   /etc/auto.home

次に、CentOS 7サーバーに新しい/etc/auto.homeファイルを最初に次の行で作成しました。

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

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

1
flashydave