私は持っています自動ファイルシステムユーザーの/homeディレクトリにある中央NFSサーバーに接続されている複数のLinuxサーバーにインストールされます。ログインした状態でディレクトリをマウントするとうまく機能しますが、インストールがタイムアウトしないようです。 /etc/sysconfig/autofsを確認しましたが、デフォルトは実際には300に設定されているため、5分後にタイムアウトする必要があります。
再起動中自動ファイルシステムすべてのディレクトリを削除してそれが可能であることを知りました。
使ってみました。ラソフディレクトリにランダムに表示されますが、いつでも開いているファイルは表示されません。
また、非アクティブ状態であることがわかっている任意のディレクトリをマウントしましたが、ディレクトリは自分でアンマウントされませんでした。このボックスの一部には、一度に10人以上のユーザーがログインしており、マウントが決して落ちません。
私は理由を見つけるためのより良い方法を見つけようとしています。どのログにも具体的な内容は表示されません。
どんな提案にも感謝します。ありがとうございます！
修正する
デバッグをオンにしました自動ファイルシステムしかし、特に珍しい点は明らかになっていないようでした。このログは、/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
答え1
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
答え2
今日はデバッグや同様の問題を解決するために数時間を費やしました。私が見つけたものと解決策は次のとおりです。 ]
設定：nfsサーバー「srv1：/ srv / homes」のユーザーホームディレクトリを含むディレクトリをクライアントの/mnt/nfs/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)
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を使用して自動マウント設定をコピーすることにしました。実際に実行してみると、この時点ではすべてがうまく機能していました。自動的にインストールされ、事前定義されたアイドル時間が経過すると自動的に削除されました。まさに。しかし、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サーバーへの変更はまったく必要ありません。
答え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
これは実際にソースを識別しません。さらに、lsof、Fuser、またはauditctl（auditd）も洞察を提供できませんでした。
結局のところ、削除プロセスでは、次の2つのアプリがあることを確認しました。
- KSysGuard（KDEシステムモニタ）
- イルカ（ファイルマネージャ）
この場合、問題のあるインストールディスクをツリービューで「隠す」ことで、ドルフィンの問題を解決できます。
KSysGuardは設定可能なようには見えませんが、何かをデバッグしない限り、長期間実行することは珍しいかもしれません。自動マウントマウントポイントの検出を防ぐために除外を許可するという点で、他のアプリケーションをより簡単に構成できることを願っています。
答え4
同様の問題があります。私はクリスマス休暇中にCentOS 6を含む10年前のRHEL 4.7 ProLiantサーバーを再インストールしました。最近（4月）CentOS 7をインストールできる最新のProLiantsが2つあります。
/etc/auto.master次のように、1行を使用してCentOS 7サーバーのCentOS 6サーバーでホームディレクトリの自動マウントを構成しました。
/home /etc/auto.home
次に、/etc/auto.homeCentOS 7サーバーに最初に1行を含む新しいファイルを作成しました。
* 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