web-dev-qa-db-ja.com

絶望的：statdがタイムアウトし、lockedは監視/監視解除できません

今日の午後からサーバーに問題があります。サーバー側では、dmesgに次のようなメッセージが表示されます。

statd: server rpc.statd not responding, timed out
lockd: cannot unmonitor <client>
statd: server rpc.statd not responding, timed out
lockd: cannot monitor <client>

クライアント側では、dmesgに表示されます。

lockd: server <server> not responding, still trying
lockd: server <server> OK

これはネットワーク全体を麻痺させています！私はこれを試しました solution Xianによって提案されましたが、違いはありません。

サーバー、Debian Linux、Squeeze 64ビット：

>> uname -a
Linux <server> 2.6.32-5-AMD64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64 GNU/Linux

クライアント、Linux Mint 13-64ビット：

>> uname -a
Linux <client> 3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

サーバーで更新を実行していないので、何が変更されたのかわかりません。クライアントマシンの1つをアップグレードしましたが、すべてのマシンが影響を受けているように見えるため、サーバーが混乱する理由がわかりません。これを修正する方法についてのアイデアはありますか？

UPDATE 1

サーバーはしばらくの間停止します

Starting portmap deamon
Starting NFS common utilities: statd idmapd

起動が続くまで約2分かかります...

UPDATE 2

これを引き起こしたのは、実際にアップグレードされたクライアントマシンです。サーバーでstatdがなんらかの原因で停止し、他のすべてのマシンで問題が発生したようです。ネットワーク全体を再起動し、その1台のマシンをオフのままにしましたが、問題は発生しませんでした。実際には修正されていませんが、その後、そのマシンを再度ダウングレードしました。すべてが安定しているようです。

linuxnfsdebian-squeezerpc
2
Markus

ここにいくつかの提案があります：

私はかつてループバックインターフェイス（lo）を壊すことができましたが、そのおかげでNFSなどのいくつかのサービスが正常に機能しなくなりました。愛するifconfigインターフェースがまだ稼働している場合は、loで確認してください。そうでない場合は、/etc/network/interfacesを参照して、何が起こっているかを確認してください。

また、すでに言及したように、コマンドpgrep -v statdおよびnetstat -tlnpuをチェックして、statdが実行されているかどうかを確認してください。

または、誰かがサーバー側の/etcの下で何かを変更しましたか？バージョン管理下に/etcがない場合は、最近変更されたファイルがあるかどうかを確認します。たとえば、find /etc -mtime -14は、過去14日間に変更されたファイルを表示します。

2
Janne Pikkarainen

ここを見てください： http://sophiedogg.com/lockd-and-statd-nfs-errors/

試してください：

# /etc/init.d/nfs-common stop
# /etc/init.d/nfs-kernel-server stop
# rm -rf /var/lib/nfs/statd/sm/*
# rm -rf /var/lib/nfs/statd/sm.bak/*
# /etc/init.d/nfs-common start
# /etc/init.d/nfs-kernel-server start

私も同じ問題を抱えていましたが、これで解決しましたが、たった1か月でした。今のところ理由はわかりません。今日もファイルを削除しなければなりませんでした。

1
Marco

これは私の場合はうまくいきました：

https://lists.debian.org/debian-user/2004/10/msg00932.html

/etc/init.d/haltスクリプトを編集するだけで、最後に次の行があるはずです

halt -d -f -i $ poweroff $ hddown

「-i」オプションを使用すると、すべてのネットワークインターフェイスがシャットダウンされますが、これはディスクレスクライアントには早すぎるようです。このオプションを削除してみてください。

停止-d-f $ poweroff $ hddown

私の問題は、ディスクを備えたクライアント上のNFSにあったことに注意してください。

0
Marco

私はnfs debian squeezeサーバーでも同じ問題があり、それはいくつかの新しいクライアント（Fedora 20）によっても引き起こされたようです。クライアントをダウングレードすることは私にとって選択肢ではありませんでした。デバッグに長く苦労して失敗した後、nfsでエクスポートされたext4ファイルシステムに次のような https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1240143

（私は間違っている可能性があります。これは最近のカーネルで修正されていることを少し理解したので、debianスクイーズが影響を受ける可能性があります）

短い話ですが、少なくともそのバグを取り除くために、nfsサーバーをdebian wheezyにアップグレードし（nfsのバージョンを3に強制）、現在（同じファイルシステムと同じクライアントで）1週間「監視できません」がありませんでした/「応答しない」問題（アップグレード前は日常的なものでした）

0
Brancomat