Fedoraがrpc-statd.serviceの代わりにrpc-statd-notify.serviceを起動するのはなぜですか?

Fedoraがrpc-statd.serviceの代わりにrpc-statd-notify.serviceを起動するのはなぜですか?

rpc-statd-notify.serviceFedora 28ワークステーションのノートブックから始まることがわかりました。

nfs-client.target私のラップトップでアクティブになっているようです。おそらく、過去のある時点でこの機能を有効にしたのでしょう。これは私の主な質問への答えです...

しかし、対照的にrpc.statd私のシステムでは起動しなかったことがわかりました。これで問題は発生しませんか?

$ systemctl status rpc-statd-notify
● rpc-statd-notify.service - Notify NFS peers of a restart
   Loaded: loaded (/usr/lib/systemd/system/rpc-statd-notify.service; static; vendor preset: disabled)
   Active: active (exited) since Tue 2018-05-08 08:02:24 BST; 4h 55min ago
  Process: 1451 ExecStart=/usr/sbin/sm-notify $SMNOTIFYARGS (code=exited, status=0/SUCCESS)

May 08 08:02:23 alan-laptop systemd[1]: Starting Notify NFS peers of a restart...
May 08 08:02:24 alan-laptop sm-notify[1451]: Version 3.1.1 starting
May 08 08:02:24 alan-laptop systemd[1]: Started Notify NFS peers of a restart.

$ systemctl list-dependencies --reverse rpc-statd-notify
rpc-statd-notify.service
● ├─nfs-server.service
● ├─nfs-utils.service
● └─nfs-client.target
●   ├─multi-user.target
●   └─remote-fs.target
[...]

$ systemctl status nfs-client.target
● nfs-client.target - NFS client services
   Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled; vendor preset: disabled)
   Active: active since Tue 2018-05-08 08:01:52 BST; 5h 28min ago

May 08 08:01:52 alan-laptop systemd[1]: Reached target NFS client services.

man sm-notify

ファイルロックは永続ファイルシステム状態の一部ではありません。したがって、ホストを再起動するとロック状態が失われます。

ネットワークファイルシステムは、リモートホストの再起動によってロック状態が失われる時期も検出する必要があります。 NFSクライアントが再起動した後、NFSサーバーは、クライアントで実行されているアプリケーションが保持しているすべてのファイルのロックを解除する必要があります。サーバーが再起動した後、クライアントは、クライアントで実行されているアプリケーションが保持するファイルロックをサーバーに通知する必要があります。

NFS バージョン 2 および 3 の場合は、ネットワークヘルスモニタプロトコル(または短縮 NSM)を使用して NFS ピアに再起動するように通知します。 Linuxでは、2つの独立したユーザースペースコンポーネントがNSMサービスを構成します。

  • SMS通知

    ローカルシステムの再起動後にNFSピアに通知するヘルパー

  • rpc.statd

    他のホストからの再起動通知を受信し、ローカルシステムが再起動したときに通知を受けるホストのリストを管理するデーモン

ローカルNFSロックマネージャは、監視する必要がある各リモートピアについてローカルrpc.statdに警告します。ローカルシステムが再起動すると、sm-notify コマンドは監視対象ピアの NSM サービスに再起動するように通知します。リモート再起動が発生すると、ピアはローカル rpc.statd に通知し、再びローカル NFS ロックマネージャに再起動通知を転送します。

FedoraはデフォルトでNFSv3クライアントシステムの再起動をサポートしていますが、サーバーシステムの再起動をサポートしていないかどうかを知りたいです。理由はありますか?つまり、サーバーを再起動すると、クライアントが保持しているロックが解除されます。これは面倒な監督かもしれません。

答え1

必要に応じてオンデマンドリリースが明らかに準備されますmount.nfsrpc-statd.serviceおそらく、これはrpc.statdNFSv4クライアントからの起動を防ぐので、不要なリソースの使用などがないことを意味します。

$ systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
[Unit]
Description=NFS client services
Before=remote-fs-pre.target
Wants=remote-fs-pre.target

# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
Wants=rpc-statd-notify.service

# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service rpc-svcgssd.service gssproxy.service

[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.target

答え2

rpc-statd損失が原因でNFSクライアントに明らかなエラーが発生しているようです。したがって、管理者はこれを認識し、何らかの結果が生じる前にそれを修正します。柔らかいロックの問題。

Jul 08 17:24:20 mount[957]: mount.nfs: rpc.statd は実行されていませんが、リモートロックに必要です。 Jul 08 17:24:20 mount[957]: mount.nfs: "-o nolock"を使用してロックをローカルに保持するか、statdを起動します。

https://forums.fedoraforum.org/showthread.php?292563-rpc-statd-starting-after-some-nfs-mounts

一方、損失はrpc-statd-notify簡単に見落とされるため、サーバーに絶えず望ましくない影響(不良ロック)が発生する可能性があります。だとしたら活性化できるよう奨励してくれたらいいなぁ…

NFSv3の起動に関する公式のRedhatドキュメントはもうありません(そしてGoogleも同様です)。素晴らしいも役に立ちます)。古い文書には伝統的に複数のサービスのアクティベーションが含まれており、rpc.statdデーモンがその一部と呼ばれる傾向があります。


しかし、私はこれらの不一致は、人々がまだrpc-statdをアクティブにし、rpc-statd-notifyをアクティブにする必要性を無視する可能性があることを意味すると思います。具体的には、rpc-statdを起動するサービスがビット自体の通知を完了したように見える初期段階からrpc-statd.serviceが設定されていることがわかりますRPC_STATD_NO_NOTIFY=1

したがって、nfs-client.target自動的に開始されず、それを有効にするサービスの1つとして言及されている文書がない場合、上記の根拠はうまくいきません。おそらくより良い説明は、それが単に古い、放置され、乱雑だということです。

しかし、これもあまり信頼できる答えではないようです。ある瞬間には必ず特別な理由があるだろういいえrpc.statdに通知部分自体を実行させる。

注:sm-notifyコマンドには、システムを再起動するたびに1回だけ実行されることを確認するチェックが含まれています。これにより、[--no-notify]オプションなしでrpc.statdが再起動されると、偽の再起動通知が防止されます。

関連情報